Download Real-Time and Embedded Guide

Chapter 7. Real-time device drivers
An operating system must interface its peripheral devices to its kernel software as well as to the user
application software. This should be done in a modular and systematic way, such that all hardware
“looks the same” to software applications. The software that takes care of this hardware-independent
interfacing are device drivers. For the Linux real-time variants, Comedi (Section 7.4) is a successful and
steadily growing project for real-time and non real-time device drivers for digital acquisition cards.
In the UNIX world, device drivers are visible through the /dev/xyz “files” (where xyz stands for a
particular device, such as, for example, hda for the first hard disk, ttyS0 for the first serial line, etc.).
The 2.4.X kernels have introduced the devfs and driverfs (“driver file system”) approaches, which give
more structure to the information about the devices that have actually been loaded. But all these things
are for user space, and hence not relevant for the real-time Linux variants that operate in kernel space.
The bookkeeping aspects of registering a device driver, with major and minor numbers, as well as
guidelines for writing device drivers, are explained in detail in the UNIX literature. For the Linux
example, Rubini’s Linux Device Drivers book ([Rubini2001]) is the major reference.
7.1. Mechanism and policy
A major feature of a good device driver is that it “provides mechanism, not policy.” This means that it
should faithfully mimic all the interfacing capabilities of the device (the “mechanism”), but nothing
more. It should not try to interpret the exchanged data in any possible user context (the “policy”),
because that is the job of that user application program itself. Indeed, once a device driver offers a
software interface to the mechanism of the device, an application writer can use this mechanism interface
to use the device in one particular way. That is, some of the data stuctures offered by the mechanism are
interpreted in specific physical units, or some of them are taken together because this composition is
relevant for the application. For example, a analog output card can be used to generate voltages that are
the inputs for the electronic drivers of the motors of a robot; these voltages can be interpreted as setpoints
for the desired velocity of these motors, and six of them are taken together to steer one particular robot
with six-degrees of freedom. Some of the other outputs of the same physical device can be used by
another application program, for example to generate a sine wave that drives a vibration shaker. Or, the
robot control program can use a force sensor that is interfaced through a serial line. The force sensor
device driver “talks” to both the application program (i.e., the force control algorithm), and the serial line
device driver (for which it is a “user application” itself!). It is obvious that the serial line driver should
never implement function calls that are only useful in the force sensor driver context. Nevertheless, that’s
exactly what happens in many projects with constrained scope, vision and time. . .
As for the other operating system responsibilities discussed in the previous Chapters, writing device
drivers for an RTOS or an EOS is not so much different from writing them for a general-purpose OS.
Basically, in an RTOS context, one should make sure that all timing delays in the drivers are both short
and deterministic, and every DSR should be an appropriately prioritized thread or handler that waits on
an event to become active.
68