+1 to what Michał said. HAL code quality is usually crap (too generic, too complicated API, poor performance and more). Anyone who has dealt with the HAL from ST or TI knows what I’m talking about. I don't know what the HAL looks like from other vendors, but HAL-based code will always be inferior to code written specifically for NuttX.
Sacrificing quality to keep vendors happy isn't a good idea - that’s Zephyr’s role :) Regarding new contributors and the small community - I doubt that support for new architectures and vendors engagement are the reason for this, especially now in the era of LLMs. czw., 24 wrz 2026 o 16:39 Michał Łyszczek <[email protected]> napisał(a): > 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"? >
