The Device Driver Philosophy

When it comes to designing device drivers, always focus on one easily stated goal: hide the hardware completely. This hiding of the hardware is sometimes called hardware abstraction. When you’re finished, you want the device driver module to be the only piece of software in the entire system that reads and/or writes that particular device’s control and status registers directly. In addition, if the device generates any interrupts, the interrupt service routine that responds to them should be an integral part of the device driver. The device driver can then present a generic interface to higher software levels to access the device. This eliminates the need for the application software to include any device-specific software. In this section, we’ll explain why this philosophy is universally accepted and how it can be achieved.

Attempts to hide the hardware completely are difficult. Any programming interface you select will reflect the broad features of the device. That’s to be expected. The goal should be to create a programming interface that would not need to be changed if the underlying peripheral were replaced with another in its general class. For example, all flash memory devices share the concepts of sectors (though the sector size may differ between chips). The following programming interface provided for a flash driver should work with any flash memory device:

void flashErase(uint32_t sector); void flashWrite(uint32_t offset, uint8_t ...

Get Programming Embedded Systems, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.