Hardware abstraction

General-purpose prototyping platforms are built and distributed by silicon manufacturers to evaluate microcontrollers and peripherals, so part of the software development may be often performed on these devices even before the design of the final product begins.

The software that can be run on the evaluation board is usually distributed as reference implementation, in the form of source code or proprietary precompiled libraries. These libraries can be configured and adapted for the final target, so they can be used as reference hardware abstraction from the beginning, and their settings updated to match changes in the hardware configuration.

On our reference target, the support for the hardware components of a generic Cortex-M microcontroller is provided in the form of a library called Cortex Microcontroller Software Interface Standard (CMSIS), distributed by ARM as a reference implementation. Silicon manufacturers derive their specific hardware abstractions by extending CMSIS. An application linked to a target-specific hardware abstraction can access peripherals through its specific API calls, and core MCU functionalities through CMSIS.

For code to be portable across different MCUs in the same family, drivers may require an additional level of abstraction on top of the vendor-specific API calls. If the HAL implements multiple targets, it can provide the same API to access generic features across multiple platforms, hiding the hardware-specific implementation under the hood. The goal of CMSIS and other free software alternatives, such as libopencm3 and unicore-mx, is to group together all the generic Cortex-M abstractions and the vendor-specific code for the most common Cortex-M silicon manufacturers, while masking the difference among platform-specific calls when controlling the system and the peripherals.

Regardless of the hardware abstraction, some of the code required at the earliest stage of the boot is very specific to each target the software is intended to run on. Each platform has its own specific address space segmentation, interrupt vector, and configuration registers displacement. This means that while working on code that is supposed to be portable among different platforms, makefiles and scripts automating the build must be configurable to link using the correct startup code and linker scripts.

The examples contained in this book do not depend on any specific hardware abstraction, as they are aimed to introduce the control of the system components by directly interacting with the system registers, implementing platform-specific device drivers while focusing on the interaction with the hardware component.