Thanks for the input and clarification Michal. That confirms my biggest
fear - the poor quality of some HALs. I don't have experience with many
HALs, but for example Microchip HALs for SAMv7 series have most of the
drivers in terrible state (not to mention Microchip have published
several different IDEs for it in past years...). Of course this doesn't
apply to all HALs, STM32's are usually the good ones.
Yes, we also have issues with our drivers and MCU support, but fixing it
is easier and more straightforward. I think we can find a compromise,
but it requires having a control over HALs ourself.
Michal
On 9/24/26 16:39, Michał Łyszczek wrote:
On 2026-09-24 11:13:55, Alan C. Assis wrote:
Re-reading again all sides, I think a middle ground is accepting a HAL,
implemented the same way it is done in Zephyr: under the RTOS umbrella.
HALs in Zephyr ARE NOT under Zephyr umbrella. HAL is 100% controlled by OEM.
Zephyr just downloads it automatically from OEM site. At least for the chips I
worked on.
Also I'll just add that adding HAL is usually a bad idea because OEM HALs just,
simply put, suck very hard. And even when I was contracted to add support for
Zephyr by OEM, I could not make changes to HAL unless there was a bug. So I had
to do weird workarounds in Zephyr code for things to work. It was not pretty.
HALs quite often introduce double buffering, locking mechanisms going via HAL,
or even interrupt handlers being triggered without RTOS knowing about it.
But hey "it worked" right? That's all that matters, right? That it "just works"?
