Porting

I’ve spent years working in the layer between customer software and firmware — the middleware that has to survive MCU swaps, silicon shortages, and last-minute BOM changes. I’ve watched teams burn weeks on firmware ports that should have taken days, and I’ve done enough post-mortems to see the same mistakes repeat across companies. These aren’t theoretical. Every mistake below comes from real porting efforts I’ve seen or been called in to fix. Most involve moving between STM32, ESP32, and nRF52 — the three families that cover probably 80% of new embedded designs in 2026. ...

You’ve been told to port the firmware from one MCU to another. Maybe the chip went EOL. Maybe the shortage made it unavailable. Maybe the new product variant needs Bluetooth and your current MCU doesn’t have it. Whatever the reason, you’re staring at tens of thousands of lines of C that were written for one specific chip, and you need them running on a different one. This guide is the process I follow. It won’t make the port painless, but it’ll keep you from wasting time on the wrong things. ...