Device driver design: a never-ending task?Builders and suppliers of embedded CPUss, boards, buses and peripherals devote a lot of effort and expense to making sure software drivers are available to link their hardware to the underlying software – most particularly the operating systems. But much of the time, developers still has to find, adapt – and if not available – build their own.
Although the operating systems are stable and change little from year to year, vendors don't always present a uniform interface between the device drivers and the I/O hardware. The reason is in the diversity and constant change in the hardware environment: new architectures, new applications and new I/O configurations. Writing drivers for each and every one is a task too daunting for any one organization to take on.
So a lot is still left up to the individual developers. But writing the device drivers appropriate for a design requires an in-depth and on-going knowledge of the operating-system internals, application programming interfaces (API) and bus protocols, as well as an in-depth knowledge of kernel-level debugging to ensure that the code activates hardware directly and correctly interfaces to other software layers to drive the hardware.
To aid experienced embedded designers in keeping themselves updated with the latest information – and introducing neophytes to the basics - this week’s Embedded.com Tech Focus newsletter includes a range of recent design articles, blogs and technical papers on the topic of device driver design. In addition to a four part series on device driver design, my Editor’s Top Picks are:
"Building reusable device drivers for microcontrollers," which describes a layered design method that allows code developed for peripheral devices to be used across a wide range of processor platforms.
"How to write DSP device drivers," in which the authors describe a DSP device-driver architecture that reduces overall driver development time by reusing code across multiple devices.
"Abstracting device-driver development ," which describes how to build in an abstraction layer into your design which contains a common set of routines that interface the hardware and device drivers, allow creation of device drivers without knowing the specific underlying hardware or processor type.
Some other Embedded.com resources to add to your knowledge base of hands-one design information about device driver design, include:
Hardware (and software) implications of Endianness in SoC design
Writing device specific, RTOS independent, hardware independent device drivers
Debugging Techniques for Linux Device Drivers
Writing Flexible Streaming I/O Device Drivers
Embedded.com Site Editor Bernard Cole is also editor of the twice-a-week Embedded.com newsletters as well as a partner in the TechRite Associates editorial services consultancy. He welcomes your feedback. Send an email to email@example.com, or call 928-525-9087.