Table of Contents
Despite attempts at standardization, each microcontroller vendor has its own methodology, which is generally incompatible, so do you need your own hardware abstraction layer?
Hardware abstraction layers (HAL) play a critical role in embedded software development. A HAL allows developers to decouple their higher-level application code from the hardware. The result is that hardware dependencies are broken, which increases the application codes’ portability, reusability, and testability. Many silicon vendors in the microcontroller space provide their customers with a HAL, but despite attempts at standardization, each has their own methodology, which is generally incompatible. Does this mean that you need your own hardware abstraction layer?
The problem with vendor-provided hardware abstraction layers (hal)
The problem with every vendor creating their own non-standardized HAL is that they will all be incompatible. That means anyone using vendor A’s HAL won’t be able to easily switch over to using vendor B. While each vendor provides a HAL to abstract the low-level details of the hardware and make using their hardware easier, they do so in a way that still vendor locks customers into using their hardware. Switching or reusing code isn’t impossible, but it is certainly more time-consuming and costly.
A secondary problem is that while there is an abstraction to the hardware, that abstraction is often tightly coupled to the hardware. The interface is usually nothing more than a direct call to the function that includes the low-level code. Developers looking to do unit testing or off-target simulation must rely on linker substitution, which can be more complex than simply remapping the interface.
Adopting your own hardware abstraction layer (HAL)
One option to solve the issue with vendor-supplied hardware abstraction layers is to adopt a standardized hardware abstraction layer. For example, you might consider using Arm’s CMSIS or adopting NASA’s OSAL. These standards can be helpful, but I’ve found that developers often struggle with them for several reasons. First, they are often overly complex because they are trying to cover all use cases for everyone. Next, that complexity increases the learning curve. Finally, these standards might not meet your preferred coding style and use abstraction mechanisms that don’t meet your needs.
A second option is to examine the existing hardware abstraction layer standards that exist and create your own hardware abstraction layer. If you custom tailor a HAL, you can ensure that the interface matches your coding style, has unit tests, and meets your technical requirements. Yes, it’s a little more work, but it will give you the flexibility to switch between different hardware vendors, test environments, and even simulate your application code. These are modern development must-haves you can’t live without if you want your team to be flexible and successful.
Do you need your own hardware abstraction layer?
That leaves us with a simple question for you to answer: Do you need your own hardware abstraction layer? The general answer depends on your customer and business’s needs. I’ve used a hardware abstraction layer in my development activities for the last decade and found that they are indispensable. The one or two times I decided to use a vendor HAL, I later regretted it. However, that doesn’t mean that will be the case for you. If you want to learn a little bit more about writing your own, you might check out a few of my other blogs on the topic, such as How to Write Epic Hardware Abstraction Layers (HAL) in C.
Jacob Beningo is an embedded software consultant who specializes in real-time, microcontroller-based systems. He actively promotes software best practices through numerous articles, blogs, and webinars on topics from software architecture design, embedded DevOps, and implementation techniques. Jacob has 20 years of experience in the field and holds three degrees including a Masters of Engineering from the University of Michigan.
Related Contents: