STM32

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. ...

Every embedded engineer has lived through this moment: your company’s chip supplier emails you that the MCU you designed around is end-of-life, or lead times just jumped to 52 weeks. You stare at 40,000 lines of firmware that call HAL_SPI_Transmit() in 200 places, and you realize your “abstraction” was just ST’s abstraction. You’re locked in. I’ve spent years writing the mid-layer software that sits between customer applications and firmware — the abstraction that’s supposed to make hardware swappable. I’ve seen what works, what doesn’t, and what looks elegant in a conference talk but falls apart when you actually need to port to a different silicon vendor. This post is the guide I wish I’d had five years ago. ...