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
