Comment by the__alchemist
1 day ago
I've had to consistently write my own libraries. HAL for STM32, LoRa support, hardware support for every sensor I use (GPS, IMUs, mag, flash memory etc), ESP-Hosted library, etc. Whenever I design something new or change parts, my assumption is I will have to write my own interface for it. It's not too bad, but is a friction point compared to if I had written the firmware in C or C++.
On the other hand, the rust embedded core tooling including the cargo/rustc/it's target system, probe-rs, defmt, and the PAC project are phenomenal, and make the most important parts one of the lowest-friction embedded workflows around!
That’s fair but when there is an async version of the driver or Hal available it should be pretty straightforward to port it to synchronous, right? Maybe Claude code can even do it with minimal supervision…
Edit: Replace blocking with synchronous
I think that's on a case-by-case basis, but from my own experiences, it's usually easier to start from scratch. A totaled car analogy, where the easier path is not modifying something existing. But it depends. Good pt. I think if the library is documented with datasheet or RM references, things are easier.
(Case in point: An example of the the "It's Async or blocking" meme I mentioned.)
In my experience most drivers are simple enough that there's not a great loss from them being reimplemented in different systems all over the place. They're fundamentally interface code, it makes sense for them to change as on of the sides of the interface changes.
(which leads to one of my embedded hot takes which is that I think striving for a generic HAL is kind of misguided. If you're striving for any form of mechanical sympathy, your HAL is almost certainly specific to at least your framework and probably actually your application)