Navigation bar
  Start Previous page  2 of 9  Next page End Home  1 2 3 4 5 6 7 8 9  

IAR Aug 2000
Implementation of device drivers sometimes requires engineering tricks, such as using
compiler-specific interrupt #pragmas, low-level hardware access from assembly
language, advanced use of the linker command file and so forth. 
Unfortunately—but not surprisingly—device driver development is more inefficient and
time-consuming compared to other software development, as Dr Matthias O’Nils
explains in his PhD thesis¹:
“Device drivers accommodate a very high information density and are dependent on
many parts that can appear in a large number of combinations. This fact is the reason
for the low productivity for device driver modelling, four times lower than ordinary
software code.”
Because of the close relationship to the hardware, traditional software tools have no or
little support for device driver development. In fact, for the most part device drivers have
been hand-crafted.
Lack of portability
Most devices have differences in their programming model, and a device driver for one
device is not likely to work with another device. Typical device differences that affect
device driver implementation are:
·
Feature set
·
SFR control/status bit configuration
·
Chip pin-out
·
Interrupt structure
·
Memory configuration
As device drivers have a tight connection to the target device and the development
environment, they are usually not portable. This reduces possibilities for code reuse and
increase the cost, time, and efforts needed to migrate a software project from one
microcontroller device to another.
Traditional development techniques
Before writing a driver library, the hardware manuals must be studied in great detail, as
both the chip internals and the electronic board design must be fully understood. This is
time-consuming and usually considered to be a rather tedious task. 
When using a new microcontroller derivative that is similar to a familiar one, it might take
just as long time to find out the difference between the two, as to understand a new
architecture. Minor—but important—changes can be well hidden as small-print
                                                  
1
Matthias O'Nils ”Specification, Synthesis and Validation of Hardware/Software Interfaces”, Royal Institute of
Technology, Stockholm.
Microcontroller.com White Papers Previous page Top Next page