Firmware

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

I write C for microcontrollers. My code talks to SPI peripherals, configures DMA channels, and runs in environments where a buffer overflow doesn’t crash a browser — it crashes a piece of industrial equipment. AI code assistants were not built for this. But I use them every day. Here’s what actually works, what’s dangerous, and where I think this is heading. What I Tested I’ve been using three AI assistants in my embedded workflow for the past year: ...

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

Most firmware teams test by flashing the board and watching an LED blink. That works until your test matrix is 200 cases, your CI pipeline needs to run on every commit, and the dev kit is on someone else’s desk. Here’s how I test firmware without hardware for roughly 80% of the test surface. The remaining 20% — timing-critical code, analog peripherals, RF — still needs real silicon. But 80% is enough to catch the bugs that matter. ...

I’ve spent the last few years writing abstraction layers between hardware and application software. Part of my job is knowing what’s out there, what works, and what breaks when you need it most. So I went through five open-source hardware abstraction layers and evaluated them on the criteria that matter for production firmware. Here’s what I found. The Evaluation Criteria I scored each HAL on five dimensions: Portability — How many MCU families does it support? How hard is it to add a new one? Performance — What’s the overhead vs direct register access? API Design — Is the API intuitive? Consistent? Does it leak hardware details? Documentation — Can a new developer figure it out without reading the source? Production Readiness — Is it used in real products? Are there gotchas? Scale: 1 (poor) to 5 (excellent). ...

Between 2021 and 2024, I watched firmware teams go through the five stages of grief. Their chip was on a 52-week lead time. The drop-in replacement didn’t exist. And their entire codebase was welded to one vendor’s HAL. Now that lead times have mostly normalized, it’s tempting to forget. Don’t. The shortage exposed a structural weakness in how most teams write firmware, and the fix isn’t “keep more inventory.” It’s in how you architect your code. ...