Re:Practical Guide to Bare Metal C++
by technothrasher on Tuesday March 10, 2026 @09:25AM
(#47322952)
I struggle with this deviating from the vendor's "happy path" often. I mostly use the STM32 chips, and I don't particularly care for their HAL library. I find it over complicated and often has bugs in it that I have to track down and fix. But boy is it nice to use their STM32CubeMX program to generate all the low level code so I can just get to work. I tend to end up building my own low level libraries during my free time because I enjoy it and it gives me a better idea of how the hardware is actually working, but using the STM32 HAL library to write my actual client code at work.
[ Parent
| on HN ]
Same experience here. What worked for me was using CubeMX purely for pin and clock config, then dropping down to the LL (low-layer) drivers or direct CMSIS register access for anything in a hot path. The HAL interrupt handlers in particular add a surprising amount of overhead — on a tight DMA transfer loop I measured ~40% cycle waste just from HAL callback dispatch.
The LL API is basically thin inline wrappers around register writes, so you still get the CubeMX-generated init code but without the HAL abstraction tax at runtime.
Also same experience here. I can write UART code with DMA in 20 lines of code on an STM32 microcontroller. Same functionality using HAL is astonishingly cumbersome. The reference manual and willingness to read it is all you need.
To be fair: If you fully rely on the ST tooling, setting up even something moderately complex, peripheral wise (like a bidirectional UART <=> USB bridge) is very straightforward because you get all the configuration/software stack just from clicking a few things in their GUI tool, then write a few lines of API calls and you're done. It's gonna be neither pretty nor especially efficient (specifically STs default HAL interrupt routines tend to be atrociously wasteful), but chances are good that it actually works immediately.
But if you want to do that from scratch with little experience, you are almost invariably gonna miss like 5 different clock/IRQ/peripheral enable flags, get some clock prescaler wrong, missconfigure a GPIO pin or two and then spend a bunch of time tracking things down with debugger, reference manual and scope...