Abstraction layer eases I/O integration
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-
cations 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 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-
quests is to have the application
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.
Alternatively, an abstraction
layer can be applied to the prob-
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,
underlying hardware or proces-
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
hardware.
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
applications to access hardware
resources such as memory, I/O,
interrupts and device registers.
Application layer
I/O driver
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 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
detailed hardware level. It func-
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
Embedded OS
kernel
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
and software issues (e.g. device-
register programming, bus-
mastering 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 por-
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-
tracted into an abstraction layer
with no specific hardware refer-
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
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 transla-
tions between virtual and physi-
cal addresses for various hard-
ware devices and as such, devel-
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
device, keep track of the time of
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
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 ad-
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
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 integra-
tion of off-board peripherals.
Then, they can more efficiently
evaluate many other I/O prod-
ucts, OS and SBCs.