Exactly, Michal. Another point is that FSP is not really a HAL; it's deeply integrated with the IDE and wasn't built with a HAL structure in mind.
Even some people inside Renesas hate it. Xiang, if the project is not to accept HAL we need a separate HAL repository to add all HALs from external vendors. Another option is to convert existing HAL based ports to native ports. To avoid the exception you just commented. BR, Alan On Thu, Sep 24, 2026 at 4:43 AM Michal Lenc <[email protected]> wrote: > > I have a different opinion here, how to integrate with the chip specific > > code it's better to decide by the chip vendor or maintainer. > > But that would mean we need to rely on chip vendors to keep maintaining > the project. What if the company decides to abandon the HAL and focus on > different projects/priorities? This happened many times in the past and > will happen in the future, company's priorities and goals can change > over time. The maintenance will then remain on us, NuttX developers, and > we can't maintain the MCU if it's not even in our codebase. > > Or what if we need some changes in HAL because of NuttX codebase, but > these changes will be rejected because the company wants to go in a > different direction with the code. There are multiple possible issues > with it and we are such strong project to be able to dictate the way how > the HAL should be implemented. > > > BTW, the community already allows Espressif and Realtek to implement the > > port on top of their HAL, why do you forbid other chip vendors to do the > > same thing? > > And imho it was a mistake we allowed it and there is no reason to repeat > it. I understand the company's perspective, it even benefits NuttX in a > short term, we get support for new chips faster and easier after all, > but managing multiple HALs is a nightmare in a long term. Even now > fixing bugs in Espressif HAL is a longer process than it would take if > everything would be in NuttX core repository. > > Michal > > On 9/24/26 04:43, Xiang Xiao wrote: > > I have a different opinion here, how to integrate with the chip specific > > code it's better to decide by the chip vendor or maintainer. > > Chip vendors need to support multiple RTOS, it's hard to require them to > > rewrite all drivers from scratch for multiple RTOS and keep the high > > quality of evolution. > > BTW, the community already allows Espressif and Realtek to implement the > > port on top of their HAL, why do you forbid other chip vendors to do the > > same thing? > > It's unfaired and will make more and more chip vendors leave NuttX and > > enter the Zephyr community. > > This is an important decision which will impact the NuttX ecosystem > deeply > > in the long term, so it's better to do some balance between the perfect > > world and the engineering practice. > > > > Thanks > > Xiang > > > > > > On Thu, Sep 24, 2026 at 10:22 AM Matteo Golin <[email protected]> > > wrote: > > > >> No, in my opinion the only thing that would address the concerns is not > >> using the HAL and instead providing a native implementation. That's the > >> NuttX take on the problem, and the HALs that have made it (like the > >> Espressif HAL) is still controversial. It's best to avoid it entirely. > >> > >> Matteo > >> > >> On Wed, Sep 23, 2026, 9:57 p.m. Binh Nguyen <[email protected] > > > >> wrote: > >> > >>> Hi Alan, Matteo, > >>> > >>> Thanks for the feedback. I understand the concern about introducing > >>> another external HAL dependency. > >>> > >>> For Renesas, reusing the FSP HAL is part of our long-term support > >>> strategy. The goal is not only to reduce the initial development > effort, > >>> but also to keep the low-level drivers aligned with vendor fixes, new > >>> device support and future FSP releases. Maintaining a separate native > >> NuttX > >>> implementation would duplicate the drivers and require an independent > >>> long-term maintenance effort. > >>> > >>> Would a Zephyr-like repository model be more acceptable? > >>> > >>> The idea would be to host the HAL repository under the NuttX > organization > >>> as the single source of truth, not as a downstream fork: > >>> > >>> - Anyone can contribute through pull requests. > >>> - The HAL's code owners maintain the HAL, review changes and > synchronize > >>> upstream updates. > >>> - NuttX committers review the NuttX integration code. > >>> - HAL repository changes require approval from the code owners. > >>> - Merge rights, CODEOWNERS, CI and branch-protection rules are > >> documented. > >>> This would give NuttX more governance over the dependency while keeping > >>> the HAL aligned with the vendor-supported FSP implementation. > >>> > >>> Would this model address the main concerns? If not, what additional > >>> conditions would be required for it to be feasible? > >>> > >>> Best Regards, > >>> Binh Nguyen > >>> > >
