Maybe we could have option for internal hal and external esp-sdk hal for users to choose?
Step by step we could have two worlds for users to choose. The biggest problem here would be WiFi and Bluetooth or more general radio stacks.. which is something unique for ESP32 chips.. still stays closed source.. and would be great to have fully open-source implementation here too :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Wed, Aug 5, 2026 at 7:56 PM Matteo Golin <[email protected]> wrote: > > I think there may be a little confusion here, because I am definitely not > disputing the obvious benefits that exist by owning our own HAL. It is > great if you can take the code into your own hands to submit patches, like > you did with the SPI driver. That is an obvious benefit of having NuttX > control over the HAL. I also agree that we shouldn't be accepting vendor > HALs into NuttX, and the exception for Espressif and Raspberry Pi is a > violation of the NuttX principles. However, it is here now. > > What I am saying needs to be considered is the other side of the coin; we > would now be required to maintain our custom HAL in perpetuity with fewer > resources than Espressif has to maintain the HAL we are currently using > from them. They add support for their new devices, have internal CI testing > that they use for NuttX, and have a large user base who are testing the HAL > through day-to-day use. We need to be sure that when and if we switch to > our own internal HAL, it is better than our current situation. That means > not just the benefit of being able to submit our own patches quicker, but > also if we will keep up to date with new Espressif devices as quickly and > have the same kind of rigorous maintenance. Why switch if it ends up being > worse quality for our users? > > I think this goal is best achieved by incrementally replacing parts of the > Espressif HAL with our own. Older chips would be much easier, since they > are stable and less of a moving target for us to catch. In the meantime, > while phasing out the HAL on those devices, we can continue to use it for > the newer chips that still have hardware revisions coming out and new > features being added. I just don't think we should bite into the entire > replacement at once. And I certainly think that we should be doing this > ourselves in areas of the codebase that make sense, not with a sweeping AI > re-write. We ultimately need maintainers of this code who understand it > well and will stick around to fix bugs and review patches. It should really > be discussed with our Espressif contributors for this reason, because right > now they are doing the majority of ESP patches and reviews. > > Best, > Matteo > > On Wed, Aug 5, 2026 at 2:57 PM Felipe Moura Oliveira <[email protected]> > wrote: > > > Hi Jorge, > > > > When I started contributing to NuttX around 2023–2024, I remember having an > > issue with the ESP32-C6 and wanting to use the ESP32-C3 driver as > > reference, which was in legacy mode. I briefly recall a contributor > > mentioning that Espressif support would be handled via the 3rd-party > > repository, and that approach was adopted. I am not sure if there was a > > formal debate regarding this methodology before I got involved. > > > > Matteo, I would like to bring up an example that I just remembered. When I > > started contributing to NuttX using an ESP32-C6, I had issues with an SPI > > Slave, which I detected and helped resolve: > > > > https://github.com/apache/nuttx/pull/14420/changes > > https://github.com/apache/nuttx/pull/14642/changes > > > > I remember in the first lecture I heard about Free Software, the benefit of > > the community criticizing, testing, and improving was highlighted. By > > inheriting a repository from a vendor, we are not doing that. The 3rd party > > code that is released today, including for NuttX, can be our reference for > > a manual port to NuttX (for new drivers, for changes). The important thing > > is to give more people the opportunity to add, review, test, and feed the > > cycle back. > > > > > > Em qua., 5 de ago. de 2026 às 15:17, Jorge Guzman <[email protected]> > > escreveu: > > > > > Hi, > > > > > > First, I'd like to understand how we ended up in this situation of using > > > third-party packages from Espressif and Raspberry Pi. > > > > > > I believe this was discussed and decided by a vote some time ago. Now, we > > > need to understand what went wrong and try to fix it. > > > > > > Espressif is one of the few companies with dedicated teams providing > > > support for NuttX, but I believe they are overloaded with other > > > responsibilities. > > > > > > At this point, the idea of creating a fork doesn't seem like a bad one to > > > me. > > > > > > Em qua., 5 de ago. de 2026 às 15:11, Tomek CEDRO <[email protected]> > > > escreveu: > > > > > > > On Wed, Aug 5, 2026 at 5:52 PM Felipe Moura Oliveira > > > > <[email protected]> wrote: > > > > > Do you really think that vendor-released firmware is guaranteed to be > > > > > functional and well-tested? > > > > > Consider Windows versus Linux. Windows is developed by a private > > > company > > > > > with its own protocols, testing processes, and so on, yet I do not > > find > > > > it > > > > > to be more stable than Linux. > > > > > > > > Try running Linux binary on a different distribution or after one year > > > > and see what "stable" means.. usually it means "stable API" :-) > > > > > > > > > Look for esp p4, when it was released it was like a beta version. > > > > > > > > Yeah, I not that long ago bought fresh board from Waveshare with > > > > ESP32-P4 and the MCU was already obsolete by two major releases. This > > > > is exactly the thing we want to avoid in NuttX world.. thus our more > > > > conservative attitude :-) > > > > > > > > -- > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > > > > > > > > -- > > > > *--Felipe Moura de Oliveira* > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0> > >
