Hi Felipe, I totally agree with you!
Although I don't like the HAL idea because of the issues already discussed (like those raised by Raiden00), supporting external HALs makes adding new MCU support easier. If we continue raising the bar and blocking vendor contributions, we will fail because companies willing to use NuttX will not get support for their chip of choice! The current situation is already very bad today, because most vendors don't even know that NuttX exists. On the other hand, all vendors support the other RTOS. BR, Alan On Thu, Sep 24, 2026 at 11:12 AM Felipe Moura Oliveira <[email protected]> wrote: > Hi Tomek, > > If NuttX continues to turn away new contributors, it will become > increasingly difficult to use professionally. > > I personally had to submit 29 PRs just to fix and adjust the ESP32-S3 > support. It is very hard to justify using NuttX to commercial management > with statistics like that, especially when Zephyr is heavily marketed as > stable and production-ready. > > We need more people actively contributing, testing, and refining code. Many > implementations start out unpolished and are refined over time. > > I am genuinely concerned about the number of new contributors appearing > only to be blocked. > > Best regards, > > Em qui., 24 de set. de 2026 às 11:05, Tomek CEDRO <[email protected]> > escreveu: > > > On Thu, Sep 24, 2026 at 1:59 PM Tomek CEDRO <[email protected]> wrote: > > > > > > On Wed, Sep 23, 2026 at 8:39 AM Binh Nguyen < > [email protected]> > > wrote: > > > > > > > > Hi all, > > > > > > > > I would like to get some early feedback on the RZ/V2H port. > > > > > > > > We are porting NuttX to the Renesas RZ/V2H Cortex-R8 and currently > > reuse the vendor-maintained FSP HAL for the low-level peripheral drivers. > > > > NuttX still owns the driver interfaces, architecture integration, > > board support, Kconfig and build integration. A thin adaptation layer > > connects the NuttX drivers to the FSP HAL. > > > > > > > > Before we prepare the upstream patches, would using RZ FSP as a > > third-party HAL dependency be acceptable to the NuttX community? > > > > I have also followed the recent esp-hal-3rdparty discussion. I > > understand that external HAL dependencies raise concerns about > governance, > > maintenance and community control, so I would like to clarify the > expected > > approach early. > > > > > > > > FSP HAL is maintained by Renesas, and our team intends to maintain > the > > NuttX RZ/V2H integration and support future FSP updates. > > > > > > > > Would this approach be feasible, and what requirements should we > > satisfy regarding licensing, version pinning, CI and long-term > maintenance? > > > > > > > > Thanks in advance. > > > > Binh Nguyen > > > > Renesas Electronics > > > > > > BIG NO to external vendor HAL, all driver should be in-tree and part > > > of the NuttX RTOS, thank you :-) > > > > > > -- > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > I am happy to bring Renesas attention to NuttX RTOS. I am not happy > > that I did not get the contract to do the job, that's life. If anyone > > else is about to do the job please please make it right from start. > > Any external HAL only makes things worse in the long run and we avoid > > that in NuttX. Thank you and have fun! :-) > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > -- > > *--Felipe Moura de Oliveira* > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0> >
