Hi Raiden, I am honestly a bit confused. During the previous Espressif discussion, it was repeatedly emphasized that they had a professional, specialized team and internal testing tools, so using their 3rd-party HAL was considered better than internalizing the code. Now you are bringing up the point that vendor HALs are poor quality.
It might be that I live in a bubble or have less experience compared to others here, but in my professional career, I have never been allowed to rewrite vendor drivers from scratch. I have previously advocated for a specific vendor because I preferred their HAL, but when senior management decides to use ST, I have to use ST along with their HAL. If issues arise, I try to solve it by myself and if I can't, I report them directly to vendor support. That has been my real-world experience. Perhaps that is why I am more flexible regarding using an existing HAL as a baseline and improving it as needed. After all, if we contribute improvements to the RTOS itself, why couldn't we do the same for the HAL? Em qui., 24 de set. de 2026 às 11:53, raiden00pl <[email protected]> escreveu: > +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"? > > > -- *--Felipe Moura de Oliveira* Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
