Appl 1340


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Appl 1340

  1. 1. 2009 IEEE International Advance Computing Conference (IACC 2009) Patiala, India, 6–7 March 2009 Implementation of Codec Driver for Network Embedded Devices B.I.D Kumar Hanumanthappa. J Thippeswamy.K Dr.Manjaiah.D.H. Assistant Professor Lecturer, Assistant Professor & HOD Reader, Dept. of Information Department of Studies Dept. Information Science & Department of Science & Engineering in Computer Science Engineering Computer Science HKBK College of University of Mysore, R.L.Jalappa Institute of Mangalore University, Engineering, Nagavara, Manasagongotry, Technology Mangalagangothri, Bangalore,Karnataka, Mysore, Karnataka, Kodigehalli, Doddaballapura Mangalore, Karnataka, INDIA. Email:- INDIA Bangalore Rural District , INDIA Karnataka, INDIA Email:- Email:- Abstract - This paper, based on implementation of a embedded devices is one of the major needs for device driver for CS4297A, an audio CODEC situated embedded systems. on embedded development Intel® PXA255 XScale® The purpose of a device driver is to handle Board [3] and Embedded Linux system which has requests made by the kernel with regards to a particular excellent network function. As companies rely on type of device. There is a well-defined and consistent applications like electronic mail and database interface for the kernel to make these requests. By management for core business operations, computer isolating device-specific code in device drivers and by networking becomes increasingly important. Meanwhile having a consistent interface to the kernel, adding a new in embedded technology also we are finding wide device is easier. requirement of network interfaced embedded devices. In the most basic sense, device drivers are those Developing device driver for this network interfaced pieces of Linux code that provide the connection embedded devices is one of the major needs for between the operating system, application and the embedded systems. hardware (the device itself). Thus, device drivers have This paper involves the study of to, among other things, deal with the asynchronous Good understanding of architecture of 32-bit character of the hardware. microcontroller like Intel® PXA255 The CS4297A is a high-performance, integrated audio CODEC. It performs stereo analog-to-digital Finding suitable Linux kernel for Intel® (A/D) and digital-to-analog (D/A) conversion of up to PXA255 processor 24-bit serial values at sample rates up to 192 kHz. The Developing a device driver for CS4297A, an D/A offers a volume control that operates with a 1 dB audio CODEC situated on target machine on an step size. It incorporates selectable soft ramp and zero Embedded Linux platform crossing transition functions to eliminate clicks and The device driver is implemented using C programming pops. The D/A’s integrated digital mixing functions language. allow a variety of output configurations ranging from a Key Words – Audio CODEC, Embedded system, channel swap to a stereo-to-mono down mix. PXA255 processor, Device Driver 2. METHODOLOGY 1. INTRODUCTION The methodology involved in writing the Driver on Industry has been very successful in design and target machines is as follows manufacture of complex embedded system, such as Detection of hardware modern vehicles (control, information, entertainment Registration with kernel (initialization) etc), monitor system, telecommunication system, Making an audio setup wireless communication systems, and the automation Opening an audio device systems. These embedded systems are becoming more Transmission of character data and more complex, distributed, interconnected Reception of character data And based on distributed computing to a larger extent. Processing of data Developing device driver for this network interfaced Releasing of device (cleaning) 2679
  2. 2. Companion Chip interface Some care must be taken while writing device drivers to Additional Peripherals for system connectivity avoid “Race condition” between processes. Linux Multimedia Card Controller (MMC) supports different synchronization tools like SSP Controller semaphores, spin lock and wait queues to avoid race Network SSP controller for baseband condition. I2C Controller Two Pulse Width Modulators (PWMs) 3. HARDWARE IMPLEMENTATION All peripheral pins double as GPIOs Hardware debug features 3.1 Intel® PXA255 XScale® Processor Hardware Performance Monitoring features It is an application specific standard product (ASSP) that provides industry-leading MIPS/mW performance for handheld computing applications. The processor is a highly integrated system on a chip and includes a high-performance low-power Intel® XScale™ microarchitecture with a variety of different system peripherals. The PXA255 processor is a 17x17mm 256-pin PBGA package configuration for high performance. The 17x17mm package has a 32-bit memory data bus and the full assortment of peripherals. Product Features High Performance Processor Intel® XScale™ Microarchitecture 32 KB Instruction Cache 32 KB Data Cache 2 KB “mini” Data Cache Fig: Block diagram Extensive Data Buffering Intel® Media Processing Technology The PXA255 processor is an integrated system- Enhanced 16-bit Multiply on-a-chip microprocessor for high performance, low 40-bit Accumulator power portable handheld and handset devices. It Flexible Clocking incorporates the Intel® XScale™ microarchitecture with CPU clock from 100 to 400 MHz on-the-fly frequency scaling and sophisticated power Flexible memory clock ratios management to provide industry leading MIPs/mW Frequency change modes performance. The PXA255 processor is ARM* Rich Serial Peripheral Set Architecture Version 5TE instruction set compliant AC97 Audio Port (excluding floating point instructions) and follows the I2S Audio Port ARM* programmer’s model. USB Client Controller High Speed UART 3.2 CS4297A audio codec Second UART with flow control UART with hardware flow control FIR and SIR infrared comm ports The CS4297 is a AC’97 1.03 compatible stereo Low Power audio Codec designed for PC multimedia systems [4]. Less than 500 mW Typical Internal Using the industry leading CrystalClear delta-sigma and Dissipation mixed signal technology, the CS4297 paves the way for Supply Voltage may be Reduced to PC’97-compliant desktop, portable, and entertainment 1.00 V PCs, where high-quality audio is required. Low Power/Sleep Modes The CS4297, when coupled with a DC’97 PCI High Performance Memory Controller audio accelerator such as the CS4610, implements a Four Banks of SDRAM - up to 100 MHz cost-effective, superior quality, two-chip audio solution. Five Static Chip Selects The CS4297 Audio Codec ’97 and CS4610 PCI Audio Support for PCMCIA or Compact Flash Accelerator are the first members of the Sound Fusion family of advanced PCI audio products for next 2680 2009 IEEE International Advance Computing Conference (IACC 2009)
  3. 3. generation multimedia PCs. 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. This programming interface is such that drivers can be built separately from the rest of the kernel, and “plugged in” at runtime when needed. This modularity makes Linux drivers easy to write. 4.2 Sound Card Technology Sound is an analog property; it can take on any value over a continuous range. Computers are digital; they like to work with discrete values. Sound cards use a Fig: Block diagram of CS4297A device known as an Analog to Digital Converter (A/D or ADC) to convert voltages corresponding to analog The CS4297 is a mixed-signal serial Codec sound waves into digital or numeric values which can be based on the AC’97 Specification. It is designed to be stored in memory. Similarly, a Digital to Analog paired with a digital controller, typically located on the Converter (D/A or DAC) converts numeric values back PCI bus. The AC’97 Controller is responsible for all to an analog voltage which can in turn drive a communications between the CS4297 and the rest of the loudspeaker, producing sound. system. The CS4297 functions as an analog mixer, a stereo ADC, a stereo DAC, and a control and digital The process of analog to digital conversion, audio stream interface to the AC’97 Controller. The known as sampling, introduces some error. Two factors CS4297 contains two distinct functional sections: are key in determining how well the sampled signal Digital and Analog. The Digital section includes the represents the original. Sampling rate is the number of AC-Link registers, power management support, SYNC samples made per unit of time (usually expresses as detection circuitry, and AC-Link serial port interface samples per second or Hertz). A low sampling rate will logic. The Analog section includes the analog input provide a less accurate representation of the analog multiplex or (mux), stereo output mixer and mono signal. Sample size is the range of values used to output mixer, stereo ADCs, stereo DACs, and analog represent each sample, usually expressed in bits. The volume controls. larger the sample size, the more accurate the digitized signal will be. 4. SOFTWARE IMPLEMENTATION Sound cards commonly use 8 or 16 bit samples at sampling rates from about 4000 to 44,000 samples per 4.1 Linux Device Drivers second. The samples may also be contain one channel (mono) or two (stereo). In the most basic sense, device drivers are those pieces of Linux code that provide the connection between the operating system, applications and the FM Synthesis is an older technique for hardware (the device itself). Thus, device drivers have producing sound. It is based on combining different to, among other things, deal with the asynchronous waveforms (e.g. sine, triangle, square). FM synthesis is character of the hardware [2]. simpler to implement in hardware that D/A conversion, The device driver is a set of functions used to but is more difficult to program and less flexible. Many control access to a device. The device drivers for sound cards provide FM synthesis for backward keyboard, monitor, mouse and Ethernet card are usually compatibility with older cards and software. Several inbuilt with Linux kernel. But when we need to access independent sound generators or voices are usually new devices for a particular application, then we have to provided. write device drivers to access them. Also, if we want to modify the default actions of the existing devices, we Most sound cards provide the capability of need to rewrite the corresponding device drivers. mixing, combining signals from different input sources Device drivers take on a special role in the Linux kernel. and controlling gain levels. They are distinct “black boxes” that make a particular 2009 IEEE International Advance Computing Conference (IACC 2009) 2681
  4. 4. MIDI stands for Musical Instrument Digital Interface, and is a standard hardware and software Figure: User space where applications reside, and kernel protocol for allowing musical instruments to space where modules or device drivers reside communicate with each other. The events sent over a MIDI bus can also be stored as MIDI files for later editing and playback. Many sound cards provide a MIDI Events User functions Kernel functions interface. Those that do not can still play MIDI files Load module insmod module_init() using the on-board capabilities of the sound card. Open device fopen file_operations:open Read device read file_operations:read MOD files are a common format for computer Write device fwrite file_operations:write generated songs. As well as information about the Close device fclose file_operations:release musical notes to be played, the files contain digitized Remove module rmmod module_exit() samples for the instruments (or voices). MOD files originated on the Amiga computer, but can be played on Table 1:-Device driver events and their associated other systems, including Linux, with suitable software. interfacing functions in kernel space and user space. 4.3 User Space and Kernel Space Events Kernel functions Read data inb When you write device drivers, it’s important to Write data outb make the distinction between “user space” and “kernel space”. Table 2:-Device driver events and their associated functions between kernel space and the hardware Kernel space. Linux (which is a kernel) device. manages the machine’s hardware in a simple and efficient manner, offering the user a simple and uniform programming interface. In the 4.4 Major and Minor Numbers same way, the kernel, and in particular its device drivers, form a bridge or interface Each character or block device is accessed through a file between the end- user/programmer and the in the file system. This file is usually located in the /dev hardware. Any subroutines or functions directory, which contains all device special files. forming part of the kernel (modules and device drivers, for example) are considered to be part These files are represented with a “c” in the of kernel space. output of the “ls –l” command, or with a “b” for a block device. User space. End-user programs, like the UNIX The output of the “ls –l” command also gives shell or other GUI based applications the major and minor numbers of the device. (kpresenter for example), are part of the user space. Obviously, these applications need The major number is an 8-bit number to interact with the system’s hardware. representing the device type. However, they don’t do so directly, but through Due to its length (8 bits), this number cannot the kernel supported functions. exceed 255. Devices using the same driver are usually represented by the ame major number on the User Space system. (Applications) A minor number usually identifies a specific Table 1 functions device among other devices sharing the same driver. This number is also stored on 8 bits, so the system is limited to 255 devices per major number. Kernel Space Assigning a major number to a device is accomplished (Modules or Drivers) in the Kernel by invoking the devfs_register_chrdev() function when the driver is being initialized. The devfs_register_chrdev() function may also register Table 2 functions major number dynamically. Similarly, the devfs_unregister_chrdev() function is used when a Hardware character is unloaded from the Kernel. 2682 2009 IEEE International Advance Computing Conference (IACC 2009)
  5. 5. Increment the usage count, so that the driver 4.5 Registration with DevFS may not be removed from the Kernel (in the case of a module). Devfs_register_chrdev() and Check for hardware-specific problems devfs_unregister_chrdev are functions provided for associated with this particular device. Kernels that do not use the new DevFS filesystem. The Initialize the hardware, if it is needed. DevFS filesystem allows the Kernel to dynamically Identify the minor number of the device that created files in the /dev directory.The register_chrdev() was open and update the f_op pointer if and unregister_chrdev() functions are still available in necessary. This is needed for device sharing the 2.4, but they were typically used in 2.2 (or older) same major number but having different Kernels.devfs_register_chrdev() and Device drivers (i.e., miscellaneous devices). devfs_unregister_chrdev() acts merely as wrappers for Allocate the memory needed for the various the old functions. This is necessary in case the DevFS data structures used in the device driver and filesystem is not available. initialize these structures. The DevFS filesystem does not necessitate the devfs_register_chrdev() and devfs_unregister_chrdev 4.7 Closing device functions. With DevFS, every files in the /dev directory could be created with devfs_register(). A sound driver is closed when a User space This new feature in the 2.4 Kernel avoids application no longer needs it. This function is executed having to manually create files in /dev with the mknod in the sys_close() system call. The release() function command. The Kernel source makes an heavy use of will not be called if it is not implemented by a specific thedevfs_register() function in almost every driver. device driver. This behavior may be observed in If the Kernel was not compiled with DevFS fput().The release() function is in charge of the support, these functions will return NULL and will be following steps: useless.Drivers may support both the old and new ways It decrements the usage count. This is of registering devices in the Kernel. necessary in order for the Kernel to be able to remove the module. The structure for devfs is described below: Removes any unnecessary data from memory. This is particularly true for data devfs_handle_t devfs_register (devfs_handle_t dir, placed in the private data field of the file const char *name, structure associated with the device. unsigned int namelen, Shut down the physical device if needed. unsigned int flags, This includes any operation that must be unsigned int major, executed in order to leave the hardware in unsigned int minor, a sane state, and disabling interrupts. umode_t mode, uid_t uid, The release () function associated with a particular gid_t gid, driver will not be invoked if the open() function was not void *ops, called. Again, this may be observed in the fput() void *info); function. Device drivers may support both the static and dynamic allocation of /dev entries. 4.8 Reading Device 4.6 Opening device read() is called to read data from the device. The form of the read function is as follows: A sound device driver is first accessed by executing its open () function. This function is executed static ssize_t device_read (struct file * file, in the sys_open() system call. The open () function will char * buffer, size_t count, loff_t *ppos) just not be called if a specific device driver does not Note that the arguments of the read () method have implement it. This behavior may be observed in changed in the 2.4 and subsequent Kernels. dentry_open (). In the case that a character needs to implement its The new method passes only a file structure, open() function, it will have to provide the following from which we can find the disk inode associated with functionality: the device file. The read() method implemented by a device driver should copy the specified number of bytes 2009 IEEE International Advance Computing Conference (IACC 2009) 2683
  6. 6. into the buffer and return the actual number of bytes Synopsis read (or an error code).The read() function may (struct file_operations * therefore read less data than was requested. In this case fops, int dev); the returned value will be less than size passed in Arguments parameter fops A negative return value means that there was File operations for the driver an error. Note that the buffer field passed to the device dev drivers refers to the memory space of the User space Unit number to allocate process that invoked the read() system call.The Description copy_to_user() function must thus be used in order to Allocate a mixer device. Unit is the number of the mixer return the data in the proper memory segment. requested. Pass -1 to request the next free mixer unit. On success the allocated number is returned, on failure a 4.9 Writing Device negative error code is returned. 4.12 unregister_sound_special The write() method implemented by a driver is Name invoked to write data to the device. It is defined as unregister_sound_special -- unregister a special sound follows: device Synopsis static ssize_t device_write(struct file *file, const char *buf, size_t count, loff_t *ppos) (int unit); Arguments write() should copy the specified number of bytes from unit the User space buffer into the device. The number of bytes specified by the value of count should be written unit number to allocate to the device. Similarly to the read() method, the number Description returned by the write() function should match the value Release a sound device that was allocated with of count. If it’s not the case, the data was partially register_sound_special. The unit passed is the return written or, in the case of a negative value, an error value from the register function. occurred. 4.13 unregister_sound_mixer 4.10 Register_sound_special Name unregister_sound_mixer -- unregister a mixer Name Synopsis register_sound_special -- register a special (int unit); sound node Arguments Synopsis unit (struct file_operations * unit number to allocate fops, int unit); Description Arguments Release a sound device that was allocated with fops register_sound_mixer. The unit passed is the return value from the register function. File operations for the driver 5. CONCLUSION unit This paper introduced an implementation of a device Unit number to allocate driver for CS4297A, an audio CODEC situated on an Description embedded development Intel® PXA255 XScale® Board Allocate a special sound device by minor number from and Embedded Linux system. As we have discussed the the sound subsystem. The allocated number is returned architecture of CS4297A, its applications and its on succes. On failure a negative error code is returned. features, it is possible to get low latency out of standard drivers, but this is still very much dependent on the 4.11 Register_sound_mixer quality of the driver. The device driver has been successfully developed for Name CS4297A and met all the requirements and has achieved register_sound_mixer -- register a mixer device 2684 2009 IEEE International Advance Computing Conference (IACC 2009)
  7. 7. all the major goals. The major features of the application the Linux Kernel : O’reilly are Portability: The application is developed in C [2] Linux Device Drivers, Alessandro Rubini & language, which in tern is coded in Linux platform, Jonathan Corbet accessibility of the software will not be a problem in any environment at the time of developing. Once the [3] Intel® PXA255 Processor Developer’s Manual software is loaded into kernel it works as kernel part. [4] Cirrus Logic, CS4297A Product data sheet 6. REFERENCES [1] Daniel P. Bovet and Marco Cesati, Understanding 2009 IEEE International Advance Computing Conference (IACC 2009) 2685