One major advantage of using microcontrollers today is that embedded software developers no longer typically need to write their own device drivers. It’s common for microcontroller vendors to provide software frameworks that abstract the hardware and enable developers to initialize, read from, and write to peripheral devices—such as SPI, UART, analog-to-digital converters, and more—with simple function calls. However, embedded developers still often need to write drivers themselves to interface with external integrated circuits, which could include sensors, actuators, motor controllers, and the like. In today’s article, we’ll explore several best practices for writing your own drivers for external devices.

Best Practice #1—Separate Implementation from Configuration

A key aspect of writing any driver is to separate the implementation from the configuration. This separation helps ensure that the driver is reusable and flexible. For example, the driver can be easily compiled into an object file, so developers won't have access to its internal details—and thus, it can be used across multiple projects. Developers can still access the configuration module, which they can use to tailor the driver to meet their specific application requirements. If the configuration needs to be adjusted, it won't affect the driver's design or force other projects that rely on the driver to fall out of sync or be compelled to adopt new changes and undergo a validation cycle.

Separating implementation from configuration also allows for abstraction of external hardware, so developers don't need to have a full understanding of what's happening inside the hardware—as is the case with microcontrollers. I often wish that integrated circuit vendors would stop providing configuration tool GUIs and instead devote their efforts to writing reusable and portable drivers for their devices. It’s extremely challenging for each of their customers to write drivers and fully comprehend their modules simply by reading data sheets that are roughly 100 pages long.

Best Practice #2—Create a Simple Underlying Interface

When writing drivers, embedded developers often try to do too much in their implementations, resulting in drivers that become a hybrid of driver and application code. A driver’s interface should feature a simple interface that includes:

An initialization function

Write a function

Read function

Anything beyond that is truly starting to enter the realm of applications! The logic behind this is simple: the driver should simply provide the ability to communicate with the device and enable read and write operations. Then, application modules will access these read and write functions to build reusable application components needed for higher-level application code.