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 .