Global Sources
EE Times-India
EE Times-India > EDA/IP

Abstraction layer eases I/O integration

Posted: 01 Feb 2005     Print Version  Bookmark and Share


PDF document

By Stephen McMillan

Chief Technologist

SBS Technologies Inc.

Device drivers are as critical to

the operation of computer pe-

ripherals and external devices

as electricity is to a light bulb.

A device driver is a software

layer between a system's appli-



(OS) uses to interact with, such

as a video display or network

adapter. Device drivers make

embedded hardware available


determines the manner in

which an embedded board will


With hundreds of single-

board computers (SBCs) and

thousands of I/O cards in the

market, there are few ready-

made I/O drivers. Hence, de-

velopers are continually re-

questing vendor support for

SBC-to-I/O integration. One

way to service developers' re-


designer send in its board sup-

port package (BSP) some soft-

ware files along with its SBC

hardware so the device drivers

can be ported by the board ven-

dor. Another way is for the de-

signer 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 de-

signer to write the I/O drivers.

In this case, the application de-

signer may have to wade

through more than 100,000

lines of code to find their spe-

cific BSP calls. Either way, the

project is delayed.



lem of I/O drivers for SBCs. An

abstraction layer is a common

set of software routines that in-

terfaces the BSP and I/O

driver, allowing a driver to be

written without needing any

knowledge of the specific BSP,


sor type. The use of an abstrac-

tion layer not only saves devel-

opers 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 off-

the-shelf, saving a lot of time

and money in software and


An abstraction layer acts as

an interface within an OS,

sitting between SBCs and driv-

ers, allowing the OS to manipu-

late the hardware. As exten-

sions of the OS, drivers enable



interrupts and device registers.

Missing from most BSPs,

though, is a set of well-defined

routines to interface the SBC

motherboard with add-on I/O



in-depth knowledge of the OS

internals, APIs and bus proto-

cols, as well as of kernel-level

debugging to ensure that the

code closest to the machine ac-

tivates I/O hardware directly

and/or interfaces to another

software layer to drive the I/O

hardware. There are also prob-

lems 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, inter-

face between the driver and

other software components, al-

lows an OS to interact with a

hardware device at a general or

abstract level rather than at a


tions like an API, but it resides

at the device level, which is be-

low the standard API level.

The abstraction layer can be

called from the OS kernel or

from a device driver, but in ei-

ther case, the calling program

interacts with the device in a

more general way than it would

otherwise, providing the devel-

oper with a key advantage--

device independence from the

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, abstrac-

tion layer, BSP and hardware.

Common routines

An abstraction layer generally

deals with low-level hardware


register programming, bus-


issues) that enable developers

to write drivers that support



tions 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 inter-

rupt occurs, control is trans-

ferred to the OS, which deter-

mines 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 an-

other. Software code for inter-

rupts is usually written directly

into the BSP, which is limiting.

If the interrupt code is ex-



ences, it can have the flexibil-

ity to drive a wider variety of

I/O hardware.

In a DMA architecture,

which allows a peripheral to

read and write to memory with-

out the intervention of a CPU,

a memory location accessed by

an application maps a virtual

address to real (physical)

memory. During the course of


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 transla-


cal addresses for various hard-


opers 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 tim-

ing device that feeds the CPU a

certain number of pulses de-

pending on the speed of the

processor, can synchronize the

data pulses between sender and

receiver in a communications


day, make this data available to

the software in a real-time ap-

plication and interrupt the

CPU at regular intervals so the

OS can divide its time between

active users and/or applica-

tions, among other functions.

Since processors run at differ-

ent speeds, the number of

pulses or ticks/second is not a

constant factor. An abstraction

A series of rectangles shows an application on top followed by an OS

kernel, I/O driver, abstraction layer, BSP and hardware.

Application layer

Embedded OS


I/O driver



Board support package

Hardware (SBC with I/O card)

layer that does not contain any

processor-specific code can be

used for clocking functions,

calling on an actual driver with


Easy integration

The common routines enabled



any knowledge of processor

types, the specific BSP or the

underlying hardware on which

it runs. Integrating a new piece


the SBC and downloading the

driver object with no compiling

required. An abstraction-layer


dition 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. De-

velopers can often use a code

from a similar SBC as a starting

point for their abstraction layer


In summary, writing drivers

for each and every 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 integra-

tion of off-board peripherals.

Then, they can more efficiently

evaluate many other I/O prod-

ucts, OS and SBCs.

Comment on "Abstraction layer eases I/O integrat..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top