Good points Michał, That is how everything works and this is how all the systems are still working, see: https://xkcd.com/2347/
It is funny because while we are thinking about moving to HAL, someone on the project where the grass is greener is proposing to adopt the NuttX way: https://github.com/zephyrproject-rtos/zephyr/issues/108088 BR, Alan On Thu, Sep 24, 2026 at 11:40 AM Michał Łyszczek <[email protected]> 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"? >
