That is true, Raiden! See, Jorge completed the GigaDevice GD32VW55x port using AI in one day.
Of course, there are improvements to make there (the GPIO config is done using GigaDevice's HAL way), but hey it is a complete port, including working WiFi and BLE support. Maybe we can find ways to spread the NuttX audience without necessarily adopting the HAL. I also don't think that the HAL support will change that. Zephyr has a stronger foundation behind it, where all member companies must contribute (code and money). BR, Alan On Thu, Sep 24, 2026 at 11:53 AM raiden00pl <[email protected]> wrote: > +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"? > > >
