Io Layer

Abstraction layer eases I/O integration By Stephen McMillan Chief Technologist SBS Technologies Inc.

Device drivers are as critical to the operation of computer peripherals and external devices as electricity is to a light bulb. A device driver is a software layer between a system’s applications and the actual hardware device that an operating system (OS) uses to interact with, such as a video display or network adapter. Device drivers make embedded hardware available to the OS, while the application determines the manner in which an embedded board will operate. With hundreds of singleboard computers (SBCs) and thousands of I/O cards in the market, there are few readymade I/O drivers. Hence, developers are continually requesting vendor support for SBC-to-I/O integration. One way to service developers’ requests is to have the application designer send in its board support package (BSP) some software files along with its SBC hardware so the device drivers can be ported by the board vendor. Another way is for the designer to sign a non-disclosure agreement with the embedded board vendor so that the source code for the device driver can be sent to the application designer to write the I/O drivers. In this case, the application designer may have to wade through more than 100,000 lines of code to find their specific BSP calls. Either way, the project is delayed. Alternatively, an abstraction layer can be applied to the problem of I/O drivers for SBCs. An abstraction layer is a common set of software routines that interfaces the BSP and I/O driver, allowing a driver to be written without needing any knowledge of the specific BSP, underlying hardware or processor type. The use of an abstraction layer not only saves developers time and money on the integration of off-board peripherals, it also evaluates different I/O products, OS and SBCs. With device driver interoperability, a customer

can choose any SBC or I/O product from a vendor, and they will all work together offthe-shelf, saving a lot of time and money in software and hardware. An abstraction layer acts as an interface within an OS, sitting between SBCs and drivers, allowing the OS to manipulate the hardware. As extensions of the OS, drivers enable applications to access hardware resources such as memory, I/O, interrupts and device registers.

hardware device at a general or abstract level rather than at a detailed hardware level. It functions like an API, but it resides at the device level, which is below the standard API level. The abstraction layer can be called from the OS kernel or from a device driver, but in either case, the calling program interacts with the device in a more general way than it would otherwise, providing the developer with a key advantage— device independence from the

Application layer

I/O driver

Embedded OS kernel

BSP abstraction Board support package

Hardware (SBC with I/O card)

A series of rectangles shows an application on top followed by an OS kernel, I/O driver, abstraction layer, BSP and hardware.

Missing from most BSPs, though, is a set of well-defined routines to interface the SBC motherboard with add-on I/O hardware. Writing I/O drivers requires in-depth knowledge of the OS internals, APIs and bus protocols, as well as of kernel-level debugging to ensure that the code closest to the machine activates I/O hardware directly and/or interfaces to another software layer to drive the I/O hardware. There are also problems associated with untested hardware—some developers may spend valuable time trying to get the I/O driver to work when their problem is really with the hardware. An abstraction layer, interface between the driver and other software components, allows an OS to interact with a

application and the OS. A fairly typical depiction of a software solution using abstraction will show a series of rectangles with an application layer on top, an OS kernel I/O driver, abstraction layer, BSP and hardware. Common routines An abstraction layer generally deals with low-level hardware and software issues (e.g. deviceregister programming, busmastering attributes and timing issues) that enable developers to write drivers that support various OS. The same is true for I/O drivers, with the major portions of common routines for I/O cards being those that handle interrupts, address translation and clocking or timing functions. Interrupts, signals that get the attention of the CPU, en-

able one bus location to output data to another. When an interrupt occurs, control is transferred to the OS, which determines the action to be taken. However, there are no naming conventions or arguments to enable or disable interrupts. Plus, interrupts are handled differently from one bus to another. Software code for interrupts is usually written directly into the BSP, which is limiting. If the interrupt code is extracted into an abstraction layer with no specific hardware references, it can have the flexibility to drive a wider variety of I/O hardware. In a DMA architecture, which allows a peripheral to read and write to memory without the intervention of a CPU, a memory location accessed by an application maps a virtual address to real (physical) memory. During the course of execution of an application, the same virtual address may be mapped to many different physical addresses as data and programs are paged out and paged in to other locations. There are no common calls that assist with address translations between virtual and physical addresses for various hardware devices and as such, developers need a file (abstraction layer) to allow the DMA engine to access those translations. Once the address translations have been resolved (using the abstraction layer software), data can be written to memory in 16-, 32- and 64bit locations, completing the transaction. The clock, an internal timing device that feeds the CPU a certain number of pulses depending on the speed of the processor, can synchronize the data pulses between sender and receiver in a communications device, keep track of the time of day, make this data available to the software in a real-time application and interrupt the CPU at regular intervals so the OS can divide its time between active users and/or applications, among other functions. Since processors run at different speeds, the number of pulses or ticks/second is not a constant factor. An abstraction

layer that does not contain any processor-specific code can be used for clocking functions, calling on an actual driver with processor-specific information. Easy integration The common routines enabled by the abstraction layer allow an I/O driver to be written without

any knowledge of processor types, the specific BSP or the underlying hardware on which it runs. Integrating a new piece of I/O hardware entails booting the SBC and downloading the driver object with no compiling required. An abstraction-layer approach facilitates the easy addition of new hardware with a

porting file that contains the abstraction routines that serve as a basis for the abstraction layer for the new hardware. Developers can often use a code from a similar SBC as a starting point for their abstraction layer routine. In summary, writing drivers for each and ever y piece of

hardware requires a massive amount of time for anyone to tackle. Using an abstraction layer to interface I/O drivers and SBCs will save customers time and money on the integration of off-board peripherals. Then, they can more efficiently evaluate many other I/O products, OS and SBCs.