Hi all,
I’m relatively new to the discussion, but I was wondering if we could also
consider an approach similar to how Zephyr handles vendor HALs.
Instead of introducing a universal adapter between NuttX and every vendor
HAL, perhaps the boundary could simply be:
Generic NuttX API
|
NuttX driver
/. \
native vendor HAL
\ /
hardware
The driver would integrate only the functionality that NuttX actually needs
from the vendor HAL. For simple peripherals, the driver could use a native
implementation directly, while more complex platforms could reuse the
vendor HAL.
The vendor HAL itself could remain an external, version-pinned dependency
managed by the NuttX build system.
This seems to avoid the need to implement and maintain a general-purpose
adapter for an entire vendor SDK, while still allowing NuttX to benefit
from existing vendor implementations.
Zephyr uses a similar principle: vendor HALs can remain external modules,
while the Zephyr drivers provide the integration with the generic Zephyr
APIs.
I’m curious what others think about this approach, especially regarding the
amount of integration and long-term maintenance work compared with
maintaining the HAL under the NuttX umbrella.
Best regards,
Ahmed
On Tue, Sep 29, 2026, 6:13 PM Tomek CEDRO <[email protected]> wrote:
> On Mon, Sep 28, 2026 at 1:35 PM Felipe Moura Oliveira
> <[email protected]> wrote:
> >
> > Hi all,
> >
> > Following the recent discussion in the thread “Early feedback on RZ/V2H
> > port and RZ FSP HAL dependency”, I would like to suggest applying the
> same
> > idea discussed there to existing vendor HAL dependencies: hosting them
> > under github.com/NuttX, while keeping them separate from the ASF
> > repositories. This proposal is aligned with some opinions shared there.
> >
> > A practical example is esp-hal-3rdparty. I recently opened a very small
> fix
> > there:
> >
> > https://github.com/espressif/esp-hal-3rdparty/pull/15
> >
> > The PR is still open without Espressif review. Interestingly, the
> technical
> > feedback so far came from Laczen, a NuttX contributor who is not part of
> > Espressif.
> >
> > This illustrates the issue when NuttX depends on a vendor repository but
> > the vendor is temporarily unavailable to maintain or review it.
> >
> > Would it make sense to move esp-hal-3rdparty, and potentially similar
> > vendor HAL repositories, under github.com/NuttX, with vendor maintainers
> > when available but NuttX committers retaining the ability to review and
> > maintain them when necessary?
> >
> > Best regards,
> >
> > *--Felipe Moura de Oliveira*
> > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
>
> I am still opponent of any external HAL/SDK in NuttX, it only brings
> problems in the long run, but if this particular HAL is already here
> we may try to experiment with it (and only this one for now) under
> github.com/nuttx umbrella to see if this approach would really solve
> any problems or add new problems. Time will tell and we can always
> fallback to the current vendor provided and controlled HAL if that
> approach fails for any reason?
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
