Bare-metal firmware porting 101 -

Bare-metal firmware porting 101

Firmware porting is becoming more commonplace. I'm sure this has to do with the amazing technological change in all embedded spaces, even bare-metal systems, which are simple systems without an operating system. Bare-metal ports have issues of their own, however.

With bare-metal ports, you're often confronted with code that is optimized for space due to the constraints with special emphasis on the past. Now with micro's packing 1 and 2 MB of space, we can begin to shift our focus on space constraints and start to incorporate more layers, so to speak, in our designs.

So let's take a look at “at-the-metal” ports. By this I mean porting the hardware layers of a design from one platform to another, safely and quickly. How do we accomplish this? If we just tear out the firmware from one platform and start wiring it into a new platform, I don't believe the results will be highly modular. It will be one of fitting a square peg in a round hole. This is where my friend and yours, “Hal” comes to the rescue.

HAL, or hardware abstraction layer, will enable you to port the firmware with less risk, greater abstraction, and fewer defects. With Hal on the job, vs. SAM (spaghetti and meatballs), things will go smoothly.

Step Number 1: Create a HAL inside of the existing legacy code.
Don't just jump over to the new platform right away. Of course, you're anxious and I'm sure management is also to see you start digging into the new platform. But we need to be methodical. So even though we have a working legacy base, and I quote, “thou shalt not lob they unholy mess just yet!” Look for those functions that are making reference to or calling into the hardware and abstract them. Place in a thin layer that on the input side is not hardware independent and on the output side is very hardware dependent. So let's say you have pulse-width modulators (PWMs) analog-to-digital converters, and basic I/O. Create “drivers” for each and be sure that the interface to them has no knowledge whatsoever of the hardware.

I would use an incremental approach (such as test driven development) to implement this layer. For example create the driver for PWM control. Test it and only after you prove it is worthy, move on to the next and the next until you are done. Once you have successfully added this layer into the old code, you can proceed to Step 2.

Step Number 2: Modify the inner working of HAL on the new platform.
Now you will find that this is a much simpler and cleaner exercise. The rest of the firmware will have its impact minimized since the interface into the hardware was tested with the same interface as with the old firmware. Sure there will be some behavioral differences and spec changes that will have some level of impact. But in general this will greatly improve your chances for success.

I hope you enjoyed this first installment on our series on firmware porting. Stay tune for more from the trenches.

Robert Scaccia is president of USA Firmware, LLC, which deploys teams to provide embedded consulting, firmware, software, hardware, product development, resourcing, and training needs. To learn more about Bob or his company, email him at or check out his website at .

8 thoughts on “Bare-metal firmware porting 101

  1. Here is my 'alternative' to Step Number 2 'Python Style' and I'm not talking about the programming language:

    Step Number 2 (The Monty Python Version): “First shalt thou take out the Holy Pin, then shalt thou count to three, no more, no less. Three shall b

    Log in to Reply
  2. Hals are ancient technology and generally suffer from lack of extensibility, poor abstraction and lack of isolation.

    Drivers are generally better than HALs – similar but different. Even better than drivers are components. A component is an instance of an

    Log in to Reply
  3. Actually you are touching on the issue. The underlying issue is that the older code may suffer from the lack of a clean isolated driver. As a result the code likely has hardware specific elements in the code vs. a simple and platform independent interface

    Log in to Reply
  4. I see you have found the “New Revised Standard” version of the Book of Armaments. (My favorite, after the Book of Hesitations.)

    On a somewhat more (ahem) serious note, one should write all device drivers as device drivers, ie some sort of open/close/read/

    Log in to Reply
  5. A HAL that has poor abstraction is clearly just broken.

    In the embedded world, that is – or at least was – often caused by the low levels being written by EE types rather than software types and EE types typically have very little understanding of good ab

    Log in to Reply
  6. Keep in mind that the emphasis is on replacing the old code with drivers. What is assumed here is that you have neither HAL nor driver in the legacy base. So to move it safely to a new environment you start with a HAL. Once moved if you intend on maintaini

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.