CHAPTER-1 INTRODUCTION

1.1 INTRODUCTION
Linux is a free open-source operating system based on Unix. Linux was originally created by Linus Torvalds with the assistance of developers around the globe. Linux is free to download, edit and distribute. Linux is a very powerful operating system and it is gradually becoming popular throughout the world. Linux is a freely distributed implementation of a UNIX-like kernel, the low level core of an operating system. Because Linux takes the UNIX system as its inspiration, Linux and UNIX programs are very similar. In fact, almost all programs written for UNIX can be compiled and run on Linux. Also, some commercial applications sold for commercial versions of UNIX can run unchanged in binary form on Linux systems. Device drivers take on a special role in the Linux kernel. They are distinct black boxes that make a particular piece of hardware respond to a well-defined internal programming interface; they hide completely the details of how the device works. User activities are performed by means of a set of standardized calls that are independent of the specific driver; mapping those calls to device-specific operations that act on real hardware is then the role of the device driver. User applications cannot directly communicate with hardware because that entails possessing privileges such as executing special instructions and handling interrupts. Device drivers assume the burden of interacting with hardware and export interfaces that applications and the rest of the kernel can use to access devices. Applications operate on devices via nodes in the /dev directory and glean device information using nodes in the /sys directory.

The embedded systems which use micro-controller such as 8-bit microcontroller as the main controller have been widely used, but most of these applications are still in the low-level stage of the embedded system.

So it is feasible to apply the high-performance 32-bit microprocessors such as S3C2440, Embedded Linux system and ADC driver application to read the data from the driver using application mode.

1.2 OBJECTIVE
The aim of the project is Implementation of ADC driver for ARM9 processor with Embedded Linux application.

1.3 PROJECT OVERVIEW

64M

Fla
Figure 1.1: Project Block Diagram

As illustrated in Fig 1.1, the ARM9, S3C2440 micro-controller has the SDRAM of 64MB on board with a clock frequency up to 100 MHZ and NAND Flash memory of 64MB with NOR Flash memory of 2MB having both non-volatile. It has 4 A/D

3inch TFT Touch Screen

3

conversion channels that can be led out, which are located on CON4_GPIO interface. For testing ADC, the AIN0 has been connected to the adjustable resistance W1 where analog input preset values controlled from the device to the target board as given in Fig 6.6. The host machine deals with serial communication or file transfer protocol (FTP) done with the transferring of data where the device opens the driver and ADC data is read. The read ADC data is been sent to the Touch Screen and Host machine using communication transfers. Every device acts as a file and the image produced by the application is been sent to the target board via DNW utility tool and the respective ADC values from the driver are been displayed in the serial console (Host machine) using Minicom and Touch Screen. Thus, it deals with monitoring the data of ADC values and controlling with USB and serial interfaces using Embedded Linux application.

1.4 THESIS ORGANISATION

The rest chapters of the thesis are organized as follows: Chapter 2 shows the porting of Linux kernel image to the MICRO2440 board. Chapter 3 illustrates the ADC driver interface and the functionalities provides with the ADC registers. Chapter 4 illustrates the overview of device drivers and classification of device drivers and describes the implementation of ADC device driver. Chapter 5 shows the compilation of the kernel. Chapter 6 gives the description of micro2440 development board, its hardware features and resources, the ARM controller and its features and presents the ADC driver architecture. Chapter 7 presents the snapshot results of this work. Chapter 8 presents conclusion on this work and gives a discussion on the scope of future work. Chapter 9 draws the references which have been the guidance through out the completion of project.

CHAPTER-2 PORTING THE LINUX KERNEL TO ARM9 PLATFORM

2.1 INTRODUCTION
Install the DNW tool on Windows. DNW is needed for all function related with image downloading through USB connection. Open DNW, USB:OK will indicated on DNW title bar if USB connection successfully.

Connect MICRO2440 board with USB cable and power on the board to enter supervivi main menu. Watch indicator on DNW title bar to check whether the USB connection is success.

2.2 INSTALLING THE COMPILED KERNEL ON ARM9 BOARD

For the Linux operating system to work on the board the following images are needed to be installed. 2.2.1 BOOT LOADER: A boot loader, also called a boot manager, is a small program that places the operating system (OS) of a computer into memory. When a computer is powered-up or restarted, the basic input/output system (BIOS) performs some initial tests, and then transfers control to the master boot record (MBR) where the boot loader resides. Most new computers are shipped with boot loaders for some version of Microsoft Windows or the Mac OS. If a computer is to be used with Linux, a special boot loader must be installed. For Linux, the two most common boot loaders are known as LILO (Linux Loader) and LOADLIN (LOAD Linux). An alternative boot loader, called GRUB (Grand Unified Bootloader), is used with Red Hat Linux. LILO is the most popular boot loader among computer users that employ Linux as the main, or only, operating system.

2.2.2 SUPERVIVI:
Vivi is bootloader made to use exclusively at ARM line processor. Supervivi is a bootloader based on Samsung open source vivi. It can be used as a tool to download and burn OS image to the flash on board. It can also be used for parameters configuration. Supervivi can be installed in either Nor Flash or Nand Flash. When Supervivi is booting from Nand Flash, user can hold down space bar in hyper terminal when board booting, to force supervivi enter main menu or supervivi will directly boot OS image by default. Because vivi supports only serial interface, to communicate between host PC and embedded system, you have to connect host PC to target board by serial cable and execute Minicom. On hyper terminal, press 'v' key as shown below.

On DNW tool, choose USB Port> Transmit/Restore to download supervivi image file. After successfully downloading, BIOS will update this new supervivi image to Nand Flash as shown below.

2.2.3 LOADING KERNEL IMAGE: The compiled kernel zImage is loaded on to the target board by pressing 'k' key on hyper terminal as shown below.

Then on DNW tool, choose USB Port> Transmit/Restore select the kernel image which is compiled with the ADC driver. The Linux Kernel image will be updated to Nand Flash after successfully downloading as shown below.

2.2.4 INSTALLING FILE SYSTEM The Linux kernel works hand in hand with what is called the root file system. This is the file system upon which the root directory can be mounted and which contains the files necessary to bring the system to a state where other file systems can be mounted, user space daemons and applications get started. The exact contents of the root file system will vary according to the computer, but they will include the files that are necessary for booting the system and for bringing it up to such a state that the other file systems can be mounted as well as tools for fixing a broken system and for recovering lost files from backups. The contents will include the root directory together with a minimal set of sub directories and files including /boot, /dev, /etc, /bin, /sbin and sometimes /tmp. To install root file system on hyper terminal press 'y' key as shown below.

Then on DNW tool, choose USB Port> Transmit/Restore to select which file system image file you want to download. Linux file system image will be updated to Nand Flash after successfully downloading The Linux file system image will be updated to Nand Flash after successfully downloading as shown below.
10

Unplug USB cable after system successfully updated. On hyper terminal press 'b' to start Linux on mini2440 board. After booting by hyper terminal, put switch S2 into NAND side and press reset button to start Linux again. Supervivi will restart and boot Linux automatically.

2.2.5 INSTALLING USB DRIVER: DNW USB driver for windows is located on CD-ROM \windowsinstall\Friendlyarmusbdriver.exe(first map). Install this driver when board connected to PC first time. Open DNW, usb:ok will indicated on DNW title bar if USB(second map) connection successfully.

11

USB device list on PC after driver installation

2.3 TESTING PERIPHERAL RESOURCES:

2.3.1 DOWNLOADING AND RUNNING 2440TEST PROGRAM: Test program 2440test can be used to test PWM beeper, RTC clock, AD converter, button, touch screen, LCD, infra, I2C bus, audio in, audio out, SD Card and CMOS Camera.
12

Install USB driver on Windows and setup Windows Hyper terminal serial cable connection. Connect USB cable and launch DNW for 2440test binary image downloading. The USB download address in DNW should be 0x30000000.

2440test program will automatically run after successfully download.

13

2.3.2 PERIPHERAL RESOURCE TESTING: AD CONVERTER TEST: User can skew W1 on board for this AD converter test.

2.4 CONCLUSION
The supervivi bootloader, kernel image, root file system images and ADC driver module is successfully loaded on to the ARM9 S3C2440 board with Embedded Linux Application.

14

CHAPTER-3 ADC INTERFACING

15

ADC & TOUCH SCREEN INTERFACE

3.1 INTRODUCTION:
In this S3C2440A, there are 4 A/D conversion channels that can be led out located on CON4_GPIO interface. For testing ADC, AIN0 has been connected to the adjustable resistance W1.

ADC:
Converts an analog input signal into 10-bit binary digital codes 8 channel, maximum 500KSPS with 2.5 MHz

Touch Screen Interface:

External transistor control logic ADC interface logic with an interrupt generation logic - Internal FET for direct Touch screen interface

3.2 FEATURES:
-Resolution: 10-bit -Maximum conversion rate: 500KSPS -Analog Input range: 0 ~ 3.3V -On-chip Sample-and-hold function -Normal conversion mode -Separate X/Y position conversion mode -Auto X/Y position conversion mode -Waiting for interrupt mode
16

ADC INTERFACI
ADC SCHEMATIC REPRESENTATION
Figure 3.1: ADC and Touch screen Interface functional Block Diagram

In ARM9, ADC driver program writes the analog signals and reads the registers where the data registers are converted and sent and finally the interrupt is generated using the interrupt request. The ADC_Channel = AIN0 where the event occurs when the interrupt is generated and value is copied to user when data is read with the pre-scale value of 0-255 as illustrated in Fig 3.1.

VDD 3V

S POT (pre-scale value button) is the interfaced directly to CON4_GPIO interface. The pre3 scale value depends on the conversion time. C AIN0 2 A 3.3 FUNCTION DESCRIPTIONS: 4 D C 3.3.1 A/D4 Conversion Time 0 A
17

The ADC input is of 10-bit data where the output of the frequency is 2.5MHz.The

When the PCLK frequency is 50MHz and the pre-scalar value is 49, total 10-bit conversion time is as follows. A/D converter freq. = 50MHz/(49+1) = 1MHz Conversion time = 1/(1MHz / 5cycles) = 1/200KHz = 5 us

3.3.2 Programming Notes: 1. The A/D converted data can be accessed by means of interrupt or polling method. With interrupt method the overall conversion time - from A/D converter start to converted data read - may be delayed because of the return time of interrupt service routine and data access time as shown in Fig 3.2. With polling method, by checking the ADCCON[15] end of conversion flag-bit, the read time from ADCDAT register can be determined. 2. Another way for starting A/D conversion is provided. After ADCCON[1] - A/D conversion start-by-read mode-is set to 1, A/D conversion starts simultaneously whenever converted data is read.

Figure 3.2: ADC and Touch Screen Operation Signal

NOTE:

18

This A/D converter was designed to operate at maximum 2.5MHz clock, so the conversion rate can go up to 500 KSPS.

3.4 PROGRAMMING THE ADC PROCESSING AND OTHER FEATURES:

For the ADC data registers, the following modes can be selected using respective table figures as shown in Table 3.1, 3.2, 3.3, 3.4 and mode of registers as given in Fig 3.3 and Fig 3.4.

19

Table 3.1: ADC and Touch Screen interface registers

Table 3.2: ADC Conversion Data register0

20

Table 3.3: ADC Conversion Data register1

Figure 3.3: ADC & TS Control Registers

Table 3.4: ADC Start Delay Register

Figure 3.4: ADC Delay Registers

21

3.5 CONCLUSION:
Input driver is taken as separate functionality for common core functions (Character device driver). ADC driver is initialized and registered using input core functionality which produces input events to create virtual inputs. The ADC and TS control registers if read it converts analog input to digital 5ms time to change the prescale value. Thus ADC driver deals with features and functionalities providing with data and delay registers using clock frequency and pre-scale time.

22

CHAPTER-4 ADC DRIVER IMPLEMENTATION

4.1 INTRODUCTION
23

The ADC driver implementation is writing the low-level drivers for ADC architecture and ADC interfacing. Here is the hard rule of resource sharing: any time that a hardware or software resource is shared beyond a single thread of execution and the possibility exists that one thread could encounter an inconsistent view of that resource. The things are to be arranged so that the code either sees memory that has been allocated or knows that no memory has been or will be allocated by anybody else. The usual technique for access management is called locking or mutual exclusion making sure that only one thread of execution can manipulate a shared resource at any time.

4.2 DEVICE DRIVERS

Device drivers take on a special role in the Linux kernel. They are distinct black boxes that make a particular piece of hardware respond to a well-defined internal programming interface; they hide completely the details of how the device works.
Def: A device driver is a small piece of software that tells the operating system

and other software how to communicate with a piece of hardware.

4.2.1 MECHANISM AND POLICY A programmer can make his own choices about the driver and choose an acceptable trade-off between the programming time required and the flexibility of the result, but the driver should be flexible, it emphasizes that the role of a device driver is providing mechanism, not policy. The distinction between mechanism and policy is one of the best ideas behind the Linux design. Most programming problems can indeed be split into two parts: what capabilities are to be provided (the mechanism) and how those capabilities can be used (the policy). If the two issues are addressed by different parts of the program, or even by different programs altogether, the software package is much easier to develop

24

and to adapt to particular needs.

4.2.2 WHEN WRITING DRIVERS When writing drivers, a programmer should pay particular attention to this fundamental concept: write kernel code to access the hardware, but dont force particular policies on the user, since different users have different needs. The driver should deal with making the hardware available, leaving all the issues about how to use the hardware to the applications. A driver, then, is flexible if it offers access to the hardware capabilities without adding constraints. Sometimes, however, some policy decisions must be made. For example, a digital I/O driver may only offer byte-wide access to the hardware in order to avoid the extra code needed to handle individual bits. 4.2.3 WHY TO WRITE DEVICE DRIVERS IN LINUX? There are a number of reasons to be interested in the writing of Linux device drivers. The rate at which new hardware becomes available alone guarantees that driver writers will be busy for the foreseeable future. Hardware vendors, by making a Linux driver available for their products, can add the large and growing Linux user base to their potential makers. And the open source nature of the Linux system means that if the driver writer wishes, the source to a driver can be quickly disseminated to millions of users. Writing drivers in Linux kernel helps in understanding how the machine works and why things arent always as fast as expected. 4.2.4 DEVICE DRIVERS CLASSIFICATION Device Drivers can be classified into statically linked drivers and dynamically linked drivers.

25

4.2.4.1 STATICALLY LINKED DRIVER Statically linked drivers are those whose object code is linked with the kernel. The code of such device driver is physically contained in the kernel and therefore loaded in memory when the system boots. 4.2.4.2 DYNAMICALLY LINKED DRIVER Dynamically drivers are those whose object code is not linked with kernel. The code of such device driver is not contained in the kernel, and the device driver is loaded and unloaded as when required.

4.2.5 ADVANTAGES OF DYNAMIC LOADING: The advantage of dynamic loading is that Linux device drivers can be integrated into the kernel in two different ways: either by compiling them into the kernel so that they are always available, or by compiling them into an object format that the kernel can load whenever access to a specific device is required 4.2.6 CLASSES OF DEVICES AND MODULES The Linux way of looking at devices distinguishes between three fundamental device types. Each module usually implements one of these types, and thus is classifiable as 1. Character devices 2. Block devices 3. Network devices

4.2.6.1 CHARACTER DEVICES

26

A character (char) device is one that can be accessed as a stream of bytes (like a file); a char driver is in charge of implementing this behaviour. Such a driver usually implements at least the open, close, read, and write system calls. The text console (/dev/console) and the serial ports (/dev/ttyS0 and friends) are examples of char devices, as they are well represented by the stream abstraction 4.2.6.2 BLOCK DEVICES Like char devices, block devices are accessed by file system nodes in the /dev directory. A block device is a device (e.g., a disk) that can host a file system. In most Linux systems, a block device can only handle I/O operations that transfer one or more whole blocks, which are usually 512 bytes (or a larger power of two) bytes in length. Linux, instead, allows the application to read and write a block device like a char device it permits the transfer of any number of bytes at a time. As a result, block and char devices differ only in the way data is managed internally by the kernel, and thus in the kernel/driver software interface. Like a char device, each block device is accessed through a file system node, and the difference between them is transparent to the user. 4.2.6.3 NETWORK INTERFACES Any network transaction is made through an interface, that is, a device that is able to exchange data with other hosts. Usually, an interface is a hardware device, but it might also be a pure software device, like the loop back interface. A network interface is in charge of sending and receiving data packets, driven by the network subsystem of the kernel, without knowing how individual transactions map to the actual packets being transmitted. Many network connections (especially those using TCP) are stream-oriented, but network devices are, usually, designed around the transmission and receipt of packets. A network driver knows nothing about individual connections; it only handles packets. ADC DRIVER comes under the class of character driver.

27

4.2.7 USER SPACE AND KERNEL SPACE

When you write device drivers, its important to make the distinction between user space and kernel space as shown in Fig 4.1.

Figure 4.1: Control flow of user request to hardware 4.2.7.1 KERNEL SPACE Linux (which is a kernel) manages the machines hardware in a simple and efficient manner, offering the user a simple and uniform programming interface. In the same way, the kernel, and in particular its device drivers, form a bridge or interface between the enduser/programmer and the hardware. Any subroutines or functions forming part of the kernel (modules and device drivers, for example) are considered to be part of kernel space. 4.2.7.2 USER SPACE End-user programs, like the UNIX shell or other GUI based applications (kpresenter for example), are part of the user space. Obviously, these applications need to interact with the systems hardware. However, they dont do so directly, but through the kernel supported functions.

28

4.2.7.3 INTERFACING FUNCTIONS BETWEEN USER SPACE AND KERNEL SPACE The kernel offers several subroutines or functions in user space, which allow the end-user application programmer to interact with the hardware as seen in Fig 2.2. Usually, in UNIX or Linux systems, this dialogue is performed through functions or subroutines in order to read and write files. The reason for this is that in Linux devices are seen, from the point of view of the user, as files.

Figure 4.2: User space and kernel space interaction On the other hand, in kernel space Linux also offers several functions or subroutines to perform the low level interactions directly with the hardware, and allow the transfer of information from kernel to user space. Usually, for each function in user space (allowing the use of devices or files), there exists an equivalent in kernel space (allowing the transfer of information from the kernel to the user and vice-versa).

4.3 THE LINUX INTERRUPT REQUEST IMPLEMNETATION

The Linux kernel provides an implementation of semaphores that conforms to the above semantics. To use interrupts, kernel code must include <asm/irq.h>. The relevant

29

type is struct clk; actual interrupt can be declared and initialized in a few ways. One is to create a static adc_clock directly, then set it up with static int adc_data: static int OwnADC=0; static struct clk*adc_clock Usually, however, struct ADC are used in a mutex mode. To make this common case a little easier, the kernel has provided a set of helper functions and macros. Thus, a mutex can be declared and initialized with one of the following: DECLARE_MUTEX(name); DECLARE_MUTEX_LOCKED(name); Here, the result is a struct ADC device variable (called name) that is initialized to 1 (with DECLARE_MUTEX) or 0 (with DECLARE_MUTEX_LOCKED). In the latter case, the mutex starts out in a locked state; it will have to be explicitly unlocked before any thread will be allowed access.

4.4 ADC DRIVER MODULES:

4.4.1 INITIALIZING THE ADC DEVICE The operations that are defined by s3c2410_adc_init are used for initializing the registers and configuring modes, the sampling rates, sampling formats, the maximum and minimum number of channels required for ADC register modes. static int _init dev_init(void) { int ret; base_addr = ioremap(S3C2410_PA_ADC, 0X20) if (base_addr == NULL) { printk(KERN_ERR Failed to remap register block\n);
30

return ENOMEM; } adc_clock = clk_get(NULL, adc); if (!adc_clock) { printk(KERN_ERR Failed to get adc clock source\n); return ENOENT; } clk_enable(adc_clock); Static is a Linux system based on a hand selected collection of the best tools for each task and each tool being statically linked It creates and use the program libraries on Linux in a static way.

4.4.2 OPERATORS FOR EACH ADC MODULE The operations that are performed by the ADC module are open, read, release and interrupt handler. static struct file_operations dev_fops = { owner: THIS_MODULE, open: s3c2410_adc_open, read: s3c2410_adc_read, release: s3c2410_adc_release, }; static struct miscdevice misc = {

31

.minor = MISC_DYNAMIC_MINOR, .name = DEVICE_NAME, .fops = &dev_fops,

4.4.3 OPENING THE DEVICE (START UP MODULE) This, s3c24xx_adc_open( ), callback is called when an ADC sub stream is opened. In this callback, initialize the runtime and allocate the memory required for private data. static int s3c2410_adc_open(struct inode *inode, struct file *filp) { init wait queue_head(&(adcdev,wait)); adcdev.channel = 0; adcdev.prescale = 0xff; DPRINTK( adc opened\n); return 0; } where adcdev.channel = 0xff is the pre-defined hardware description.

4.4.4 INITIALIZING THE INTERRUPT HANDLER This, static irqreturn_t adcdone_int_handler( ), callback is called when an ADC sub stream handles with an interrupt function. In this callback, it initializes the interrupt data and wait for the device and allocate the memory required for the data which is produced by the interrupt request.

32

static irqreturn_t adcdone_int_handler(int irq, void *dev_id) { If (OwnADC) { adc_data = ADCDAT0 & 0x3ff; ev_adc = 1; wake_up_interruptible(&adcdev.wait); } Return IRQ_HANDLED; }

4.4.5 SHUTTING DOWN THE ADC This, s3c24xx_adc_release(struct inode *inode, struct file *filp), is called when adc sub stream is closed. Any private instance for an adc substream allocated in the open callback will be released here. static int s3c2410_adc_release(struct inode *inode, struct file *filp) { DPRINTK (adc closed\n); } 4.4.6 ADC FUNCTIONALITY /* normal ADC*/ ADCTSC=0; ret = requestr_irq(IRQ_ADC, adcdone_int_handler, IRQF_SHARED,

33

DEVICE_NAME, &adcdev); if (ret) { iounmap(base_addr); return ret; } ret = misc_register(&misc); printk (DEVICE_NAME\t initialized\n); return ret; } The normal ADC has a functionality of disabling the touch screen register and handle the interrupt request to ADC using shared mode hereby declaring the devices and unmap the base address to it. The misc_register so called initializes the device name and return the data value of the driver to input sources. ADC driver in Linux with enhanced data register is an example of miscellaneous register.

4.5 CONCLUSION
The reasons in the writing of Linux device drivers are the open source nature of the Linux, the rate at which new hardware becomes available and the hardware vendors, by making a Linux driver available for their products, can add the large and growing Linux user base to their potential makers. The role of the device driver should be written such that it implements mechanism not as policy. The ADC driver implementation is writing the low-level drivers for ADC architecture using system calls and ADC interfacing with the data registers using ARM9.

34

CHAPTER-5 KERNEL COMPILATION

35

5.1 INTRODUCTION
For compiling the kernel on the ARM9 board, cross compiler environment should be created. A cross compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is running. Cross compiler tools are used to generate executables for embedded system or multiple platforms. It is used to compile for a platform upon which it is not feasible to do the compiling, like microcontrollers that don't support an operating system. It has become more common to use this tool for Para-virtualization where a system may have one or more platforms in use.

5.2 ESTABLISHING CROSS-BUILD ENVIRONMENT:

GCC, a free software collection of compilers, can be set up to cross compile. It supports many platforms and languages. GCC requires that a compiled copy of binutils be available for each targeted platform. Especially important is the GNU Assembler. Therefore, binutils first has to be compiled correctly with the switch --target=some-target sent to the configure script. GCC also has to be configured with the same --target option. GCC can then be run normally provided that the tools, which binutils creates, are available in the path, which can be done using the following (on LINUX-like operating systems with bash): PATH=/path/to/binutils/bin:${PATH} make

The following steps should be done to install it. Step1: Get the latest arm gcc cross compiler source code. Copy the arm-linuxgcc-4.3.2.tgz tar file to a directory such as (/opt/Friendlyarm/micro2440).here extract the tar file as follows: # tar xvzf arm-linux-gcc-4.3.2.tgz -C /

36

Step2: Add the compiler path to the system environment variables, run the command. # vim / root /.bashrc

Edit / root /.bashrc file, at the end of the file add the following line. export PATH = $ PATH: / usr/local/arm/4.3.2/bin Then save the file and exit. The decompression process is shown below in Fig 5.1.

Figure 5.1: Decompression process of Arm Linux Gcc

5.3 COMPILING THE KERNEL WITH DEFAULT CONFIGURATION FILE The kernel contains thousands of device drivers, file system drivers, network protocols and other configurable items. The kernel configuration is the process of defining the set of options with which you want your kernel to be compiled.
37

The set of options depends -On your hardware -On the capabilities you would like to give to your kernel.

Go to the working directory # cd /opt/FriendlyARM/micro2440

Extract the above tar file here. # tar xvzf linux-2.6.29-micro2440-20090331.tgz

It will create linux-2.6.29 directory, which contains the complete source code of Linux kernel-2.6.29. Use the default configuration file to configure and compile the kernel. config_micro2440_n35 - apply NEC3.5 "LCD in the kernel configuration file Go to the Linux kernel directory as shown in Fig 5.2: #cd /opt/Friendlyarm/micro2440/linux-2.6.29

Figure 5.2: Linux Kernel Directory

38

Copy the default configuration file config_micro2440_n35 to a file .Config as follows # cp config_micro2440_n35 .Config

Figure 5.3: .bashrc Root File In Fig 5.3, it gives the .bashrc root file. In order to take effect the above installation, restart the system. After rebooting the system put the arm-linux-gcc-v in command prompt. The following message appears, indicating that cross-compiler environment has been successfully installed in Fig 5.4.

39

Figure 5.4: Installation of Cross Compiler environment Then do make menuconfig. The kernel configure interface appears as seen in Fig 5.5. # make menuconfig

Figure 5.5: Linux Kernel Configuration Then do not make any changes to the main menu, select <Exit> out, and select Yes to Save settings and back to Command line interface. This is done to generate the configuration header file as shown in Fig 5.6.

40

Figure 5.6: Generation of Configuration Header file Enter the following command to start the kernel compile. # make zImage

41

After compilation, the build Linux kernel image file (zImage) can be route to arch / arm / boot directory.

The zImage is downloaded to the development board for test using DNW utility under windows.

5.4 CUSTOMIZING LINUX KERNEL:

Above we have used the default configuration file and compiled the kernel, in fact there are many configuration options in Linux kernel, and it helps u become familiar with the kernel configuration, in order to customize your core needs. A default configuration file, such as config_N35, has the process to customize the kernel such as After running make menuconfig, the main menu of the kernel configuration appears as given in Fig 5.7.

42

Figure 5.7: zImage of Linux kernel file

5.4.1 AD CONVERSION DRIVE CONFIGURATION: In character device menu select ADC driver for friendly arm as shown in Fig 5.8

Figure 5.8: ADC Driver for Friendly ARM

5.5 CONCLUSION:

43

Configuring and compiling the linux kernel is done with default configuration file using static loading/dynamic loading specifically providing with Character devices and creating the zImages to the development board.

44

CHAPTER-6 MICRO2440 DEVELOPMENT BOARD

6.1 INTRODUCTION:
45

The MICRO2440 is an efficient ARM9 development board with a reasonable price, it characterizes simple method and high performance-price ratio. Based on the Samsung S3C2440 Microprocessor, it embodies professional stable CPU core power source chip and reset chip to ensure the stability of the system operation. The PCB on the MICRO2440 board is designed to be 4-Layers board, adopting the ENIG technology and professional equal-length wiring to ensure the completeness of the signals of the key signal wire; and manufactured and released under stringent quality control plans.

6.2 PHYSICAL APPEARANCE OF MICRO2440:

The physical appearance of MICRO2440 is shown in Fig 6.1

Figure 6.1: Physical appearance of MICRO2440

6.3 HARDWARE FEATURES:

46

CPU

- Samsung S3C2440A 400MHz Main Frequency 533Mhz Peak Frequency

SDRAM

- 64M SDRAM on board - 32 bit data bus - SDRAM clock frequency can reach up to 100MHz
Flash Memory

- 64M Nand Flash on board, non-volatile - 2M Nor Flash on board, non-volatile

LCD control

- A 4-wire resistive touch screen interface is integrated on the board, via which the 4-wire resistive touch screen can be connected
Interfaces and Resources

- One 10MM Ethernet RJ-45 interface (DM9000 Ethernet chip adopted) - 3 serial ports - One USB Host - One stereo audio output interface, one MIC interface
System clock source

- 12M passive crystal

OS supported

- Linux 2.6 - WindowsCE.NET 5.0

47

6.4 HARDWARE RESOURCE:

6.4.1 ARM9 PROCESSOR An ARM processor is any of several 32-bit RISC (reduced instruction set computer) microprocessors developed by Advanced RISC Machines, Ltd. The ARM architecture was originally conceived by Acorn Computers Ltd. in the 1980s. Since then, it has evolved into a family of microprocessors extensively used in consumer electronic devices such as mobile phones, multimedia players, pocket calculators and PDAs (personal digital assistants). 6.4.1.1 ARM FEATURES The ARM architecture is a Reduced Instruction Set Computer (RISC) architecture, as it incorporates these typical RISC architecture features: Large uniform register file Load/store architecture, where data-processing operations only operate on register contents, not directly on memory contents Simple addressing modes, with all load/store addresses being determined from register contents and instruction fields only. In addition, the ARM architecture provides: Instructions that combine a shift with an arithmetic or logical operation Auto-increment and auto-decrement addressing modes to optimize program loops Load and Store Multiple instructions to maximize data throughput Conditional execution of almost all instructions to maximize execution throughput.

48

These enhancements to a basic RISC architecture enable ARM processors to achieve a good balance of high performance, small code size, low power consumption, and small silicon area. The ARM Instruction Architecture is constantly improving to meet the increasing demands of leading edge applications developers, while retaining the backwards compatibility necessary to protect investment in software development. ARM uses the Universal Assembly Language to provide a canonical form for all ARM and Thumb instructions. This allows the user to write assembly code which can be assembled for either instruction set.

6.4.1.2 REGISTER SET The ARM processor has thirty seven registers, some of which have conditions applied, so you only get to use sixteen at any one time...

Register 0 to register 7 are general purpose registers and can be used for ANY purpose. Unlike 80x86 processors which require certain registers to be used for stack access, or the 6502 which places the result of mathematical calculations in the Accumulator, the ARM processor is highly flexible in its register use.

Register 8 to register 12 are general purpose registers, but they have shadow registers which come into use when you switch to FIQ mode. Register 13 is typically the OS stack pointer, but can be used as a general purpose register. This is an operating system issue, not a processor issue, so if you don't use the stack you can corrupt this freely within your own code as long as you restore it afterwards. Each of the processor modes shadow this register.

Register 14 is dedicated to holding the address of the return point to make writing subroutines easier. When you branch with link (BL) the return address is stored in R14. Likewise when the program is first run, the exit address is stored in R14. All instances of R14 must be preserved in other registers (not really efficient) or in a stack. This register is shadowed across all of the processor modes. This register

49

can be used as a general purpose register once the link address has been preserved. Register 15 is the program counter. It holds the status of the processor as well as a twenty-six bit number which is the address of the program currently being used. Additionally, some ARM9 cores incorporate "Enhanced DSP" instructions, such as a multiply-accumulate, to support more efficient implementations of digital signal processing algorithms. The ARM920T is based upon the ARM9TDMI processor core to which instruction and data caches have been added. The instruction and data ports are merged via an AMBA bus master unit, and a write buffer and memory management unit are also incorporated. The overall organization of the ARM920T is illustrated in Fig 6.2.

Figure 6.2: ARM920T Organization.

50

6.4.2 MEMORY MAP AND CHIP SELECTION The S3C2440 CPU chip supports two kinds of boot modes: booting at the Nand flash (which is used by the MICRO2440) and booting at the Nor flash. The allocation of the storage space of the chip selections is different in the two boot modes.

6.4.3 SDRAM Two 32MB SDRAM chip (HY57561620FTP, 4Banks x 4MBit x 16bit)) are utilized on the MICRO2440. The two chips are joined up in parallel to produce 32bit data bus width so as to increase access speed, both of them use the nGCS6 as the chip election, and thus, the physical offset of these two SDRAM chips are determined to be 0x30000000. The Fig 6.3 below shows the schematics of the SDRAM chips

Figure 6.3: Schematics of SDRAM chips

51

6.4.4 FLASH STORAGE: Two Flash storage chips are used on the MICRO2440. One is 2MB Nor Flash (Model: SST39VF1601), the other is 64MB Nand Flash (Model: K9F1208). Both of these two storages can be used as boot source, i.e., the system can boot from either Nor Flash or Nand Flash. By switching the switch S2, we can select either Nor Flash or Nand Flash as boot source. There is no address wire in the Nand Flash, it is connected to the CPU via a special controller, with a data bus width of 8-bit. A 8-bit data bus width does not mean a slow access speed, in fact most of the u-disks and SD cards are made of Nand Flash chips. The Fig 6.4 below shows the schematics of the NAND and NOR flash. The Nor Flash is connected to the CPU via 22 address wires (A1-A22) and 16 data wires. The address starts from A1, which determines that the minimum write/read unit is 2 byte, therefore, the Nor Flash supported by MICRO2440 maximally is 8 Mb. In fact, on the MICRO2440, only A1-A20 are used, therefore the pins on the SST29V1601 which are connected to A21 and A22 are floating.

52

Figure 6.4: Schematics of NAND and NOR flash 6.4.5 SERIAL PORTS The S3C2440 micro-controller itself has 3 serial ports in total, namely UART0, UART1, UART2. The UART0 and UART1 can be combined as a full-functional serial port. In most practices, only three simply serial port functions are used, i.e., send (TXD) and receive (RXD), they are respectively related to the connectors CON1, CON2 and CON3. CON1, CON2, and CON3 are three TTL serial ports directly led out from the CPU.

6.4.6 USB INTERFACES: There are two USB interfaces on the MICRO2440. One is USB Host interface and the other is USB Device interface. The USB Host is the same with USB interfaces on a PC, it can be used to connect USB camera, USB keyboard, USB mouse, U-disk and etc.; The USB Device interface is usually used for downloading programs to the MICRO2440 or WinCE synchronization. For controlling the communication between the USB Device and PC, a signal USB_EN is set as shown in the Fig 6.5, which uses the CPU resource GPC5.

53

Figure 6.5: Schematic of USB interfaces to MICRO2440. 6.4.7 ETHERNET INTERFACE: A 10/100M self-adapting Ethernet chip DM9000 and an Ethernet connector RJ45 are used on the MICRO2440. The RJ45 connector contains a coupled inductor, therefore a simple Ethernet cable is used to connect the MICRO2440 development board to a router or switch. 6.4.8 ADC ARCHITECTURE The 10-bit CMOS ADC (Analog to Digital Converter) is a recycling type device with 8-channel analog inputs. It converts the analog input signal into 10-bit binary digital codes at a maximum conversion rate of 500KSPS with 2.5MHz A/D converter clock. A/D converter operates with on-chip sample-and-hold function and power down mode is supported. Touch Screen Interface can control/select pads (XP, XM, YP, YM) of the Touch Screen for X, Y position conversion. Touch Screen Interface contains Touch Screen Pads control logic and ADC interface logic with an interrupt generation logic.

Figure 6.6: ADC Detailed Block Diagram

54

6.4.9 ADC OUTPUT On the MICRO2440, totally there are 4 A/D conversion channels that can be led out, which are located on the CON4-GPIO interface as given in Fig 6.6. For the convenience of testing ADC, the AIN0 has been connected to the adjustable resistance W1 as shown in Fig 6.7.

Figure 6.7: Schematic of ADC Output

6.5 CONCLUSION
The MICRO2440 is an efficient development board with Samsung S3C2440 ARM processor whose main frequency is 400MHz. The S3C2440 microprocessor, the register set of ADC and ADC interfacing are described in the next subsequent sections. The ADC Architecture is the Linux-input subsystem. The input core is a common functionality between all the device drivers. The input device driver is a interface between input core and input device which is provided by the library of functions. The core also plays an important role in exporting the ADC API to higher applications.

55

CHAPTER-7 RESULTS

56

7.1 INTRODUCTION Virtual File System is an application file pointer with virtual addresses and physical addresses. It acts like a file which is been bi-directed (as copy from or to the user) with Ethernet device driver and Character device core.

Console

Figure 7.1: Architecture diagram Character Device core is been controlled by the preset value through ADC Device driver using AIN0 pin where the values can be skewed continuously using W1 (POT) pre-scale value button on target ARM9 board. Pre-scale value button is a variable register and depends totally on the conversion time. It initializes the /dev directory and opens the devices so that data from the driver can be read and sent to the data register. Input core is a functionality between all functions declared with specific device driver. Ethernet Device driver which is been communicated with FTP protocol provides the values which is been read by the driver and send the application data of ADC values to target board and minicom serial console as given in Fig 7.1.

Virtual Terminal

57

7.2 TRANSFERRING IMAGE USING FTP:

7.2.1 COPY THROUGH MEDIA Step1: First copy the compiled executable file to flash drive. Mount the Usb flash drive using following command. # mount/dev/sda1/mnt Copy just the compiled program to the flash drive as follows: # cp *.* /mnt

Step2: Put the flash drive into the development board's USB Host Interface, USB will automatically mount to /udisk directory, perform the following command in target board command prompt. # cd /udisk Insert the compiled modules on to the target board.

7.2.2 TRANSFERRING THE ADC TEST FILE

Procedure:

1) FTP login to target board, 2) Upload compiled file. 3) Modify (change Executable attributes) the uploaded program in the target board. On the PC-side connect to the target board with the ftp login with the command #ftp 192.168.1.230

58

Enter the name and password as plg as shown below. Transfer the binary files with the command put followed by binary file name. Transfer the binary files with the put command as shown below.

After transferring files successfully to the target board on the target side open the minicom with the following command #minicom The transferred files are in the directory /home/plg.

The properties of the binary file should be changed to the executable with the command. # chmod 777 adc-test

The ADC driver helps in dealing with the functionality of ADC data values which is transferred using static loading. Here by it enhances with the ADC application where it is programmed to open the ADC driver and read the values of it using serial communication and transfer the data to target board using file transfer protocol.

59

60

61

CHAPTER-8 PROJECT CONCLUSION

8.1 CONCLUSION
62

The project deals with the implementation of ADC device driver using Embedded Linux Application development for ARM9. It is carried out using ftp and serial port communication. The application helps in reading the data from the driver and sending the ADC data values to serial console. The memory size of the statistically compiled zImage of ADC driver is 1.92MB. When running ADC application, the memory usage is 32.4% and CPU usage is 7.1% using x86 processor. Similarly, the memory usage for ARM9 processor is 2.3%. The average load when running an ADC test gradually decreases with a time difference of 0.32 to 0.23 secs and from 0.23 to 0.14 secs.

8.2 FUTURE WORK

This is an efficient implementation of ADC Device Driver using Embedded Linux. Advanced issues like, via user space devices, Touch Drivers for minicom are just a few to mention. These are future scope of this project.

63

CHAPTER-9 BIBLIOGRAPHY

9.1 BIBLIOGRAPHY

64

REFERENCES: 1) Linux Device Drivers, Third Edition By Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman Publisher: O'Reilly Media Released: February 2005. 2) Beginning Linux@Programming, Third Edition By Neil Matthew, Richard Stones Published by Wiley Publishing, Inc. 3) Embedded Linux Premier, A Practical Real-World Approach, Publisher: Prentice Hall, September 2006. 4) Essential Linux Device drivers, By Sreekrishnan Venkateshwaran, Publisher: Prentice Hall, March 2008. 5) C Programming and data structures, By Balaguru Swamy, Tata-McGraw-Hill, 2nd edition.

WEBSITES: http://www.friendlyarm.net http://www.thaieasyelec.net http://www.elinux.org http://www.datasheetcatalog.com http://www.kernel.org http://www.linuxjournal.com/magazine

65

APPENDIX A. LINUX

A.1 INTRODUCTION TO LINUX:

66

Linux is a computer operating system which is based on free and open source software. Although many different varieties of Linux exist, all are Unix-like and based on the Linux kernel, an operating system kernel created in 1992 by Linus Torvalds. Linux can be installed on a wide variety of computer hardware, ranging from mobile phones, tablet computers, routers and video game consoles, to desktop computers, mainframes and supercomputers. Linux is a leading server operating system, and runs the 10 fastest supercomputers in the world. The development of Linux is one of the most prominent examples of free and open source software collaboration; typically all the underlying source code can be used, freely modified, and redistributed, both commercially and non-commercially, by anyone under licenses such as the GNU General Public License. The name "Linux" comes from the Linux kernel, originally written in 1991 by Linus Torvalds. The main supporting user space system tools and libraries from the GNU Project (announced in 1983 by Richard Stallman) are the basis for the Free Software Foundation's preferred name GNU/Linux.

A.2 PROGRAMMING LANGUAGES:

Linux is written in the version of the C programming language supported by GCC (which has introduced a number of extensions and changes to standard C), together with a number of short sections of code written in the assembly language (in GCC's "AT&Tstyle" syntax) of the target architecture. Because of the extensions to C it supports, GCC was for a long time the only compiler capable of correctly building Linux. In 2004, Intel claimed to have modified the kernel so that its C compiler also was capable of compiling it. There was another such reported success in 2009 with a modified 2.6.22. The primary difference between Linux and many other popular contemporary operating systems is that the Linux kernel and other components are free and open source

67

software. Linux is not the only such operating system, although it is by far the most widely used. Some free and open source software licenses are based on the principle of copyleft, a kind of reciprocity: any work derived from a copyleft piece of software must also be copyleft itself. The most common free software license, the GNU GPL, is a form of copyleft, and is used for the Linux kernel and many of the components from the GNU project as shown in Linux Development model in Fig A.1.

Figure A.1: Linux Development Model

A.3 LINUX VERSIONS:

68

Linux kernels come in two flavors: stable or development. Stable kernels are production-level releases suitable for widespread deployment. New stable kernel versions are released typically only to provide bug fixes or new drivers. Development kernels, on the other hand, undergo rapid change where (almost) anything goes. As developers experiment with new solutions, often-drastic changes to the kernel are made. Linux kernels distinguish between stable and development kernels with a simple naming scheme. Three numbers, each separated by a dot, represent Linux kernels. The first value is the major release, the second is the minor release, and the third is the revision. The minor release also determines whether the kernel is a stable or development kernel; an even number is stable, whereas an odd number is development. Thus, for example, the kernel version 2.6.26 designates a stable kernel as given in Fig A.2. This kernel has a major version of two, has a minor version of six, and is revision zero. The first two values also describe the "kernel series" in this case, the 2.6 kernel series.

Figure A.2: Kernel version naming convention Development kernels have a series of phases. Initially, the kernel developers work on new features and chaos ensues. Over time, the kernel matures and eventually a feature freeze is declared. At that point, no new features can be submitted. Work on existing features, however, can continue. After the kernel is considered nearly stabilized, a code freeze is put into effect. When that occurs, only bug fixes are accepted. Shortly thereafter

69

(one hopes), the kernel is released as the first version of a new stable series. For example, the development series 1.3 stabilized into 2.0 and 2.5 stabilized into 2.6.

A.4 PROPERTIES OF LINUX:

A.4.1 LINUX PROS A lot of the advantages of Linux are a consequence of Linux' origins, deeply rooted in UNIX, except for the first advantage, of course: Linux is free: Linux can be downloaded in its entirety from the Internet completely for free. No registration fees, no costs per user, free updates, and freely available source code in case you want to change the behavior of your system. Linux is portable to any hardware platform: A vendor who wants to sell a new type of computer and who doesn't know what kind of OS his new machine will run, can take a Linux kernel and make it work on his hardware, because documentation related to this activity is freely available. Linux is secure and versatile: The security model used in Linux is based on the UNIX idea of security, which is known to be robust and of proven quality. But Linux is not only fit for use as a fort against enemy attacks from the Internet: it will adapt equally to other situations, utilizing the same high standards for security. The development machine or control station will be as secure as firewall. The Linux OS and most Linux applications have very short debug-times: Because Linux has been developed and tested by thousands of people, both errors and people to fix them are usually found rather quickly. It sometimes happens that there are only a couple of hours between discovery and fixing of a bug.

70

A.4.2. LINUX CONS There are far too many different distributions: "Quot capites, tot rationes", as the Romans already said: the more people, the more opinions. At first glance, the amount of Linux distributions can be frightening, or ridiculous, depending on the point of view. But it also means that everyone will find what he or she needs. Linux is not very user friendly and confusing for beginners: It must be said that Linux, at least the core system, is less user friendly to use than MS Windows and certainly more difficult than MacOS, but... In light of its popularity, considerable effort has been made to make Linux even easier to use, especially for new users. More information is being released daily, such as this guide, to help fill the gap for documentation available to users at all levels.

A.5 ARCHITECTURE OF LINUX OPERATING SYSTEM:

Kernel: The Linux kernel includes device driver support for a large number of PC hardware devices (graphics cards, network cards, hard disks etc.), advanced processor and memory management features, and support for many different types of file systems (including DOS floppies and the ISO9660 standard for CDROMs). In terms of the services that it provides to application programs and system utilities, the kernel implements most BSD and SYSV system calls, as well as the system calls described in the POSIX.1 specification. The kernel (in raw binary form that is loaded directly into memory at system startup time) is typically found in the file /boot/vmlinuz, while the source files can usually be found in /usr/src/linux. The latest version of the Linux kernel sources can be downloaded from http://www.kernel.org. The Linux operating system architecture is shown in Fig A.3.

71

Figure A.3: Linux Operating System architecture Shells and GUIs: Linux supports two forms of command input: through textual command line shells similar to those found on most UNIX systems (e.g. sh - the Bourne shell, bash - the Bourne again shell and csh - the C shell) and through graphical interfaces (GUIs) such as the KDE and GNOME window managers. If you are connecting remotely to a server your access will typically be through a command line shell. System Utilities: Virtually every system utility that you would expect to find on standard implementations of UNIX (including every system utility described in the POSIX.2 specification) has been ported to Linux. This includes commands such as ls, cp, grep, awk, sed, bc, wc, more, and so on. These system utilities are designed to be powerful tools that do a single task extremely well (e.g. grep finds text inside files while wc counts the number of words, lines and bytes inside a file). Users can often solve problems by interconnecting these tools instead of writing a large monolithic application program. Application programs: Linux distributions typically come with several useful application programs as standard. Examples include the emacs editor, xv (an image viewer), gcc (a C compiler), g++ (a C++ compiler), xfig (a drawing package), latex (a

72

powerful typesetting language) and soffice (StarOffice, which is an MS-Office style clone that can read and write Word, Excel and PowerPoint files). Redhat Linux also comes with rpm, the Redhat Package Manager which makes it easy to install and uninstall application programs.

A.6 LINUX FLAVOURS:

A.6.1 LINUX AND GNU Although there are a large number of Linux implementations, a lot of similarities exist in the different distributions, if only because every Linux machine is a box with building blocks that you may put together following your own needs and views. Installing the system is only the beginning of a long term relationship. Just when you think you have a nice running system, Linux will stimulate your imagination and creativeness, and the more you realize what power the system can give you, the more you will try to redefine its limits. A.6.2 GNU/LINUX The Linux kernel is not part of the GNU project but uses the same license as GNU software. A great majority of utilities and development tools, which are not Linuxspecific, are taken from the GNU project. Because any usable system must contain both the kernel and at least a minimal set of utilities, some people argue that such a system should be called a GNU/Linux system.

A.7 CHARACTER DEVICE DRIVER:

Character devices do data transfer character by character ex: keyboard, mouse and parallel port. A character driver drives a character device. A char driver is in charge of implementing the behavior of character device.

73

Linux identifies devices and their drivers with the help of two eight bit numbers. Major number Minor number

Major numbers and Minor numbers: The major number identifies the driver associated with the device. The kernel uses the major number at open time to dispatch execution to the appropriate driver. The minor number is used only by the driver, other parts of kernel dont use it and merely pass it along to the driver.

A.7.1 Creating a device file: The command to create a device node on a file system is mknod, superuser privileges are required for this operation. This command takes three arguments in addition to the name of the file being created. mknod mydev c 254 0 Creates a char device whose major number is 254 and minor number is 0. Minor numbers should be in the range of 0 to 255 because they are sometimes stored in a single byte.

A.7.2 Getting Major number: -Major number: in case of static allocation, specify an unused major number, - Zero in case of dynamic allocation. -TEST is the name for the driver - &fops address of struct file_operations.

74

A.7.3 Removing a driver from system: When a module is unloaded from the system, the major number must be released. This is accomplished with the following function, which u call from the modules cleanup function. int unregister_chrdev(unsigned int major, const char *name);

A.7.4 Two ways of allocation of major number for a driver: -Statistically -Dynamically Static Allocation: Specify an unused major number as first argument to register_chrdev. Linux specifies a group of unused numbers for experimental and development purposes. Dynamic Allocation: The kernel itself obtains major device number from the unused numbers. Request can be made as dynamic assignment of a major number.

A.8 FILE OPERATIONS:

Struct file_operations contains pointers to functions performed on our device through our driver. The file_operations structure has been slowly getting bigger as new functionality is added to the kernel. int(*open)(struct inode*,struct file*); This operation is invoked when the file structure is being released. Like open, release can be missing. int(*release)(struct inode*, struct file*);

75

Used retrieving data from the device. A null pointer in this position causes the read system call to fail with EINVAL(Invalid argument).A non-negative return value represents the number of bytes successfully read. ssize_t(*read)(struct file*,char*,size_t,loff_t*); Sends data to the device. If missing, -EINVAL is returned to the program calling the write system call. The return value, if non-negative, represents the number of bytes successfully written. ssize_t(*write)(struct file*,const char*,size_t,loff_t*);

A.9 FILE STRUCTURE:

Struct file, defined in <linux/fs.h>, is the second most important data structure used in device drivers. A FILE is defined in the C library and never appears in kernel code. A struct file on the other hand, is a kernel structure that never appears in user programs. The file structure represents an open file. It is created by the kernel on open and is passed to any function that operates on the file, until the last close. After all the instances of the file are closed, the kernel releases the data structure. An open file is different form a disk file, represented by struct inode. In the kernel sources, a pointer to struct file is usually called either file or filp(file pointer).Thus file refers to the structure and filp to a pointer to the structure.

A.9.1 The open method: In most drivers, open should perform following tasks: Increment the usage count Check for device-specific errors

76

Initialize the device, if it is being opened for the first time. Identify the minor number and update the f_op pointer, if necessary. Allocate and fill any data structure to be put in filp->private_data. In char, most of the preceding tasks depends on the minor number of the device

being opened. Bit splitting is a typical way to use minor numbers.

A.9.2 The release method: The role of release method is the reverse of open. The method implementation is called device_close instead of device_release. Either way, device should perform following tasks: - De-allocate anything that open allocated in filp->private_data. - Shut down the device on last close. - Decrement the usage count. The basic form of char has no hardware to shut down, so the code required is minimal. int char_release(struct inode *inode, struct file *filp) /*close function of a character

A.9.3 Read and Write: The read and write methods perform a task that is copying data from and to the application code. ssize_t read(struct file *filp,char *buff,size_t count, loff_t *offp); /*prototype of read and write*/ ssize_t write(struct file *filp, const char *buff,size_t count,loff_t *offp);

77

For both methods, filp is the file pointer and count is the size of the requested data transfer. The buff argument points to the user buffer holding the data to be written or the empty buffer where the newly read data should be placed. Finally, offp is a pointer to a long offset type object that indicates the file position the user is accessing.

A.9.4 Read method: The return value for read is interpreted by the calling application program as follows: If the value equals the count argument passed to the read system call, the requested number of bytes has been transferred. This is the optimal case. If the value is positive, but smaller than count, only part of the data has been transferred. If the value is 0, end-of-file was reached. A negative value means there was an error. The value specifies what the error was, according to <linux/errno.h>.These errors look like EINTR (interrupted system call) or EFAULT (bad address). A.9.5 Write method: Write can transfer less data than that was requested, according to following rules for the return value: If the value equals count, the requested number of bytes has been transferred. If the value is positive, but smaller than count, only part of the data has been transferred. The program will most likely retry writing the rest of the data. If the value is 0, nothing was written. This results is not an error, and there is no reason to return an error code. Once again, the standard libraries retries the call to write. A negative value means an error occurred, like for read, valid error values are those defined in <linux/errno.h>

78

The char code for write deals with a single quantum at a time like the read method does.

A set of API subroutines (typically system calls) interface to hardware. Device drivers hide the implementation and hardware-specific details from a user program and typically uses a file interface metaphor. Device is a special file.

Linux character device type supports the following operations Open: only one is allowed. Write: writes a char string to the top of device stack. Error if stack is empty Read: reads an item from top of the device stack. Error if stack is empty Release: release the device

A.10 OPERATING INSTRUCTIONS:

A.10.1 Selecting Boot mode: Boot mode can be selected by S2, according words on silk screen S2 connect to Nor Flash side system will boot from Nor Flash S2 connect to Nand Flash side system will boot from Nand Flash BIOS which pre-loaded in Nor Flash and Nand Flash are the same in shipment. By default, S2 had been connected to Nand Flash.

79

A.11 LINUX OPERATIONS:

Linux was pre-loaded as default OS before shipment. This default linux image is root_default.img. With support by Linux, user can test the functionalities of almost all of hardware resources on the board.

A.11.1 Aborting running programs: Press Ctrl+c to stop running of a program. Use kill to stop a program running on back ground A.11.2 Transfer file with PC User can transfer (sz/rz) files with PC when he/she login linux by serial console. A.11.3 Setting up MAC address #ifconfig

#ifconfig eth0 down #ifconfig eth0 hw ether 00:11:AA:BB:CC:DD

80

#ifconfig eth0 up #ifconfig

A.11.4 Transmitting Files via FTP:

81

A.12 INSTALL LINUX

Linux binary image file is in /image/linux folder. Connect MICRO2440 board with USB cable and power on the board to enter supervivi main menu. Watch indicator on DNW title bar to check if USB connection success.

A.12.1 Setting the Hyper-terminal:

A.13 MINICOM
A.13.1 Introduction Minicom is a communication program which somewhat resembles the shareware program TELIX but is free with source code and runs under most unices. Features include dialing directory with auto-redial, support for UUCP style lock files on serial devices, a separate script language interpreter, capture to file, multiple users with individual configurations, and more.

A.13.2 Minicom setup

82

The -s option use to setup minicom. Type the following command at shell prompt the screen will appear as shown below: $ minicom -s -c on

To configure minicom as serial port use up and down arrows to select menus press down and select Serial port setup. The screen will appear as shown below.

Configure serial port with minicom A - Serial Device: /dev/ttyS0 B - Lockfile Location: Linux systems use /var/lock. If this directory does not exist, minicom will not attempt to use lock files. C - Callin Program: This is the program to get into dial in mode. D - Callout Program: This to get into dial out mode. E - Bps/Par/Bits: 9600 8N1

83

F - Hardware Flow Control: Yes G - Software Flow Control: No Press 'Enter' to save the settings. To save all settings to the /etc/mini com/minirc.dfl file select 'Save settings as dfl'. To exit Minicom when in terminal mode press 'Ctrl-A' to get a message bar at the bottom of the terminal window and then press 'X'. A.13.3 File Transfer Protocol (FTP) is a standard network protocol used to transfer files from one host to another host over a TCP-based network, such as the Internet. FTP is built on a client-server architecture and utilizes separate control and data connections between the client and server

A.14 THE LINUX DIRECTORY LAYOUT

/bin This contains binary files that can be used both by the root user and ordinary users, but are essential to operation in single-user mode, when some other directory structures may not be mounted. For example, core commands such as cat and ls would normally be found in here, as will sh. /boot This directory is used for files required during booting of the Linux system. It is frequently quite small, less than 100 MB, and often a separate partition. This is handy on PC-based systems, where there are frequently BIOS limitations on the active partition, requiring it to be in the first 2G or 4G of the disk. Having this as a separate partition allows more flexibility when deciding how to lay out the rest of the disk partitions. /dev This contains the special device files that map to hardware. For example, /dev/hda will be mapped to the first IDE disk. /etc

84

This contains configuration files. Historically some binaries could also be found in here, but that is no longer true on most Linux systems. The best-known file in the /etc directory is probably passwd, which contains information on users. Other useful files are fstab, listing mount options; hosts, listing IP to host name mappings, and the httpd directory, which contains configuration for the Apache server. /home This is a directory for user files. Normally each user will have a single directory under this directory with the same name as their login, and this will be their default login directory. For example, after logging in, the user rick will almost certainly find himself in the /home/rick directory. /lib This contains essential shared libraries and kernel modules, specifically those that will be required while the system is booting or in single user mode. /mnt This is simply a convenient place for mounting additional file systems temporarily. Normally there will be subdirectories for the different devices, such as /cdrom and /floppy. /root This is for files used by the root user. It is not in the /home directory part of the tree, because that may not be mounted in single-user mode. /sbin This is used for commands normally used only by the system administrator, and required while the system is booting or in single user mode. Commands such as fsck, halt, and swapon live here. /usr

85

This is a rather complex secondary file system, generally containing all the system-type commands and libraries not required during system booting or in single user mode. It has many subdirectories, such as /bin, /lib, /X11R6 and /local. /opt This is a directory for software vendors to use when adding software applications. By convention, distributions generally dont use it for software they distribute as part of the standard distribution, but leave it free for third-party vendors to use. Generally, vendors will create a subdirectory with their name, and then further subdirectories such as /bin and /lib for files specific to their application. By convention, most Open Source Linux packages use /usr/local for installation. /var This contains data that changes frequently, such as spool files for printing, application log files, and mail-spooling directories.

A.15 LINUX COMMANDS

File/Directory Basics ls cp mv rm ln cd pwd List files Copy files Rename files Delete files Link files Change directory Print current directory

mkdir Create directory rmdir Delete directory File Viewing

86

cat less head tail

View files Page through files View file beginning View file ending

File Creation and Editing emacs Text editor vim File Location Find Locate files slocate Locate files via index which Locate commands File Text Manipulation grep cut tr sort tee Search text for matching lines Extract columns Translate characters Sort lines Copy stdin to a file and to stdout simultaneously Text editor

paste Append columns

File Compression gzip zip Compress files(GNU Zip) Compress files(Windows Zip) bzip2 Compress files (BZip2)

File Comparison diff cmp Compare files line by line Compare files byte by byte comm Compare sorted files

87

A.16 CREATING ARCHIVE FILES

A ".tar" file is not a compressed files, it is a collection of files within a single file uncompressed. If the file is a .tar.gz ("tarball") or ".tgz" file it is a collection of files that is compressed. If you are looking to compress a file you would create the tar file then gzip the file.

A.16.1 TAR.GZ
To compress a directory use the following syntax: # tar -zcvf archive_name.tar.gz directory_to_compress To decompress an archive use the following syntax: # tar -zxvf archive_name.tar.gz This will extract the files in the archive_name.tar.gz archive in the current directory.

A.16.2 TAR.BZ2
To compress a directory use the following syntax: # tar -jcvf archive_name.tar.bz2 directory_to_compress This will extract the files in the archive_name.tar.bz2 archive in the current directory. To extract the files to a different directory use: # tar -jxvf archive_name.tar.bz2 -C /tmp/extract_here/

88