Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Intro to bare-metal firmware porting

Posted: 18 Jun 2013     Print Version  Bookmark and Share

Keywords:Firmware porting  Bare-metal  HAL  hardware abstraction layer  PWMs 

Firmware porting is becoming more ordinary. I am certain 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.

About the author
Robert Scaccia is a firmware consultant and president of USA Firmware, LLC. He is very active with a large network of firmware consultants throughout the United States and Canada, is chair of the IEEE Cleveland Computer Society, and founded the largest regional, as well as international, firmware group on LinkedIn.

Comment on "Intro to bare-metal firmware porting"
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top