5 Ways a Hardware Abstraction Layer Can Transform Your Projects

Jacob Beningo | Jun 05, 2023

Embedded software developers have typically avoided hardware abstraction layers (HALs) by claiming that they decrease performance and increase code complexity. Unfortunately, when developers adopt a HAL, a vendor-provided HAL often doesn't abstract the hardware and still guarantees tight coupling to the hardware. After all, a real abstracted HAL would enable a developer to use any vendor at the drop of a hat. However, there are many ways that using or developing your own HAL can impact your software. In this post, we will explore five surprising ways a HAL can transform your software projects and unleash speed and value you didn't realize was possible.

I’ve generally found that developers often have a favorite microcontroller vendor. It's usually the vendor you first wrote your embedded software on or that you are familiar with. I have my favorites just like anyone else, but it can be dangerous to write your software dependent on their HAL or software libraries. For example, what do you do if you suddenly can't get their microcontrollers? You’d have to select a new supplier and then rewrite, test, and maybe even certify your product. That is not fast or cheap! While you might think this is unlikely, it happened during COVID and many times before.

Using a good HAL will allow you to write more portable and reusable application code that is hardware independent. That is a massive transformation for many embedded teams. For example, you could run your code using Vendor A and, by changing a flag in your build, be compiling for Vendor B. Hardware independence gives you the flexibility to use any hardware you desire and removes your dependence on your microcontroller vendor.

If you like the idea of using the vendor-supplied HAL, that is ok as long as you review several essential features. First, the HAL must be a real HAL. That means you must have a defined interface that breaks the hardware dependency. We discussed this in my blog entitled "Writing Hardware Abstraction Layers (HALs) in C." I often see "HALs" that are nothing more than functions with the implementation. That doesn't obey the dependency inversion principle and is just as hard to update code. Next, the HAL should be defined separately from the implementation. Finally, you should be able to swap out the function called by the interface quickly. If you don't have these three things, then you don't have hardware independence; you have hardware dependence!

The key to unlocking value and transforming your software development starts with using a HAL. The HAL further enables additional transformations like enabling automated unit and integration testing. Embedded developers often struggle with unit testing because they write code that touches the hardware. That means you must run your tests on the microcontroller. When you have a proper HAL in place, yes, you still need to test your drivers on the target, but all your application code is suddenly freed! Your application code can now be unit and integration tested on a host machine independent of the hardware.

Removing the hardware from the equation and moving testing to the host benefits developers. First, it's faster. You don't have to worry about all those slow erase and write cycles on the part. Second, you don't need to worry about how big your test harness is getting or how many tests you have. Instead of trying to fit your code and tests on the microcontroller, you just test all the application code on your host first. Next, moving to test off-target allows you to utilize continuous integration and even continuous deployment if you choose. The result will be catching bugs sooner and faster, decreasing costs, and improving quality.

When you get the hardware out of the equation using a good HAL, it allows you to put any implementation behind it. That means you can have an implementation for your target, your test harness, and a simulation environment! In many cases, embedded software developers must start writing software before hardware is available. So while we can use development boards to get started, with a good HAL, we can run simulations on our application code instead!

Simulating application code comes with many advantages for developers. First, it allows them to get the application code in front of their customers sooner rather than later. We all know that customers love to change their minds and have difficulty visualizing how a product will work until they can play with it. Simulation can help the customer understand the product and provide productive feedback sooner, decreasing expensive and time-consuming changes later in the development cycle.

Next, simulation enables more robust testing by allowing faults and other aberrant behaviors to be tested without the hardware. For example, getting a sensor to misbehave or forcing a hardware exception on the target processor can often be challenging. In a simulation environment, this isn't a problem. The result again is more robust software.

When you debug on target, every time a change is made, there is a cycle of cross-compile, erase flash, program flash, and run the application. The whole process can take quite a while, depending on the application, even with professional tools. Using a HAL to separate the application allows the code to be debugged faster! On a host, the compile and run cycle is much shorter. That means developers can work through issues more quickly and then test the final debugged version on their hardware when necessary.

If you allow the other transformations a HAL provides to come to fruition, you’ll use unit tests to drive development, meaning you’ll even spend less time debugging. You’ll only write code to make a test pass. Your software will be written in small increments, with tests validating it all along the way. If you break something, regression tests will catch it immediately. The result will be faster, more-efficient debugging and the near complete removal of debugging from your life and project! Doesn't that sound wonderful?

The ultimate transformation for using a HAL to develop embedded software is that you’ll decrease costs and time-to-market. A HAL creates flexibility in the embedded software that most teams never dream about. You can easily see that if you can get customer feedback quickly, you’ll have less rework late in the development cycle. In addition, if you can eliminate debugging, that's huge! Most teams spend, on average, 20–40% of their development cycle debugging! That's 2.4–4.5 months a year per person! All because you used a HAL that enables the ability to test your application code and reduce debug time.

With decreased times to market, it becomes evident that the cost will be less. There certainly is an investment in HAL development, test harnesses, and other tools to ensure the development cycle goes smoothly. However, those costs are often an order of magnitude less than what will be saved. I haven't even mentioned expenses related to maintenance which can easily outweigh initial development costs.

I’ve often had clients and colleagues comment on how much I can get done. The secret has been that I’ve unlocked the transformations that a HAL can provide to embedded developers. As you’ve seen in this post, using a "real" HAL can dramatically transform your project and how you develop embedded software.

Some of the transformations we've discussed might seem a bit foreign because embedded software developers have traditionally not used these techniques. However, it doesn't take much time to get up to speed on them and allow them to improve how you develop embedded software dramatically. You’ve seen the benefits; the question is whether you’ll embrace them and start building a microcontroller-independent HAL into your software. If you do, I think you’ll revolutionize how you develop your embedded products.

More information about text formats