Hi, I just want to point out that NuttX already has API that does that, lower and upper drivers. Upper driver is generic, lower is chip specific. API is not stable but it is generic.
I am still convinced that NuttX should have native chips (without HAL) in repository and HAL supported chips as external integrations that are not fully tied to the merge and release cycle of NuttX. I still think that we should limit the need of core NuttX developers to understand every single HAL that could be, in some capacity, included and move that to dedicated maintainers (prefferably vendor supplied). That doesn't mean outside NuttX commiters reach, it means that most of the work would be done by dedicated developers with deeper knowledge of external source code (HAL) and not by NuttX developers improving drivers. Even if HAL supported chips would lag behing NuttX core. With regards Karel On Tue 29 Sep 2026 07:39:53 PM , Ahmed Ashraf wrote: > 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 > >
signature.asc
Description: PGP signature
