Device driver design: a never-ending task? - Embedded.com

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 , or call 928-525-9087.

See more articles and columns like this one on Embedded.com.Sign up for the Embedded.com newsletters . Copyright © 2013 UBM–All rights reserved.

5 thoughts on “Device driver design: a never-ending task?

  1. “Writing drivers for each and every one is a task too daunting … ” But that's not the task at hand. A hardware company can choose one system, one model, that they're going to support, because they have to write some level of driver in order to prove th

    Log in to Reply
  2. It's great to have this information to study and learn about Device drivers, but is the problem described really so?
    I'm not working on this end but surely am interested. Is it really a moving target to be making device drivers?

    Log in to Reply
  3. Re Luis Sanchez, from my regular cruising of various forums both company and noncompany related I am constantly seeing pleas of help about driver problems – finding one, making it work, etc. Most recent one I saw was on Embedded.com's forum titled: “Develo

    Log in to Reply
  4. “Although the operating systems are stable and change little from year to year…” I am nit sure what OS you are talking about, but the internal Linux interfaces for drivers, file systems, etc change all the time.

    I generally find that most board/SoC vend

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.