HAL

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

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