Developing reusable device drivers for MCUs

The rate at which society expects products to be released and refreshed has been steadily decreasing over the last two decades. The result has left development teams scrambling to implement the most basic product features before the product launch date. Designing a new product from scratch takes time, effort and money that is often unavailable.

Embedded software developers often look to chip manufacturers to provide example code and drivers for their processors to help accelerate the design cycle. Unfortunately the provided code often lacks a layered architecture that would allow the code to be easily reused. In addition, the code is often sparingly documented which makes fully understanding what is being done difficult. The result is poorly crafted code that is difficult to read and comprehend that offers no possibility of reuse with the next product. Time and effort is forced to focus on developing low level drivers rather than on implementing the product features at hand.

This paper will explore methods and techniques that can be used to develop reusable abstracted device drivers that will result in a sped up development cycle. A method for driver abstraction is examined in addition to a brief look at key C language features. A layered approach to software design will be explored with common driver design patterns for Timers, I/O, and SPI which can then be expanded upon to develop drivers for additional peripherals across a wide range of processor platforms.

Driver Code Organization
There are many different ways in which software can be organized. In fact, nearly every engineer has their own opinion on how things should be done. In this paper, with the intention of creating reusable drivers and reusable design patterns, the software will be broken up into layers which will include driver and application layers. The primary focus will be on the driver layer with the intent that the same basic principles can be applied to higher layers.

The driver layer will consist of peripheral interface code as one would expect; however, the drivers will attempt to remain generic to the peripheral. This will allow them to be used and configured for any range of applications. The driver layer can be compiled into a separate library that can then be dropped into any project. The configuration for each driver would be contained within configuration modules that would be part of its own layer. Each application can then uniquely configure the driver and application layers to match the requirements. Figure 1 shows how the configuration and driver code would be organized.

Figure 1 – Layered Organization

Application Programming Interface (API’s)
One of the most critical steps in developing a reusable driver framework is to define the Application Programming Interface (API’s). Properly defining the API’s allows for a standard interface to be used to access hardware across multiple platforms and projects. This is something that high level operating systems have done relatively well over the years.

There are many possible ways in which these API’s can be defined and is often dictated by programmer preferences. For this reason, the developed API’s should become part of the development teams’ software coding standard. The end goal is to define the API’s in a way that meets general requirements of the system but allows the power of each peripheral to be fully utilized.

There are software API’s available that can provide a starting point. It is possible to adopt formats used by the Linux kernel, Arduino libraries, AUTOSAR, or a custom driver API that is a mix. It really doesn’t matter provided that the format is well documented and used across all platforms and projects.
It is useful to define the API’s for common and useful features for each of the peripherals. Each peripheral will require an initialization function in addition to functions that allow the peripheral to perform its functions. For example, Listing 1 shows a possible interface for a Digital Input/Output driver. It consists of an initialization function, a read, write and toggle function.

Listing 1 – Digital Input/Output API