Zephyr

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