I strongly oppose this suggestion, so my vote is no. Matteo
On Wed, Aug 5, 2026, 11:42 a.m. Felipe Moura Oliveira <[email protected]> wrote: > Hi all, > > Using AI in this situation might not be that bad. It is almost like using a > translator. We would take what already exists and works, and ask the AI to > adapt it to our case. > > For example, we could start with an isolated and simple driver, like SPI. > We could ask the AI to use the 3rd-party HAL as a reference and convert it > using the standard patterns we already use in stm32. We can approach this > incrementally, one driver at a time. > > If you agree, I can create a Proof of Concept (PoC) for this. > > > *--Felipe Moura de Oliveira* > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0> > > On Wed, 5 Aug 2026 at 12:33 Matteo Golin <[email protected]> wrote: > > > The ESP HAL change is a massive undertaking. Having AI relegated to do it > > means that we are going to get an even larger increase of AI generated > PRs, > > and now ones that entirely compose a very critical layer of a highly > > popular vendor device collection on NuttX. Are we going to convince > > Espressif developers to help maintain an AI generated copy of their HAL? > > How are we going to obtain their feedback in the development of a new HAL > > that lives within NuttX? Which developers are going to have an > > understanding of this AI generated HAL? How will it be copyrighted? How > > will we ensure it doesn't violate licensing? > > > > If we move to a NuttX maintained ESP HAL, which is already a large ask, > it > > should be created and maintained by NuttX incrementally to ensure that > it's > > stable, license compatible and has some support from our Espressif > > contributors who have been maintaining our ESP support so far. AI > > generating it in one shot is going to be a huge headache for maintainers. > > It also, in my opinion, pushes us one step closer to being yet another > slop > > project. > > > > Matteo > > > > On Wed, Aug 5, 2026, 11:26 a.m. Marco C. <[email protected]> > wrote: > > > > > Can you please elaborate? > > > > > > > > > Marco Casaroli > > > > > > On Wed, Aug 5, 2026 at 17:23 Matteo Golin <[email protected]> > > wrote: > > > > > > > No. > > > > > > > > On Wed, Aug 5, 2026, 11:21 a.m. Marco C. <[email protected]> > > > wrote: > > > > > > > > > Should we AI-convert all espressif HAL into in-tree nuttx? > > > > > > > > > > It would take a few days, and we can guarantee that the build are > > > > > bit-by-bit matched in day zero, then we would have control of the > > tree > > > > and > > > > > will need to maintain it. > > > > > > > > > > Does not sound too bad. > > > > > > > > > > What do you think? > > > > > > > > > > Marco Casaroli > > > > > > > > > > On Wed, Aug 5, 2026 at 17:16 Tomek CEDRO <[email protected]> wrote: > > > > > > > > > > > NuttX by design and by rule uses its own in-tree hardware > > > > > > implementation for archs, platforms, mcus, boards, drivers, etc, > so > > > it > > > > > > is a self-contained and self-sufficient environment. There are > two > > > > > > exceptions to this rule Espressif and RaspberryPi, unfortunately. > > > > > > > > > > > > We are aware of the issue and its pros and cons. There is not > much > > we > > > > > > can do about ESP because of the design of their tools. Yes it is > a > > > > > > moving target.. whoever worked with standalone esp-idf knows > that. > > > > > > > > > > > > Pros: > > > > > > + There is a dedicated team in Espressif for NuttX development > that > > > > > > maintains the esp-sdk components. > > > > > > + We have always up to date implementations and features. > > > > > > + Easy migration between different ESP chips inside NuttX > > ecosystem. > > > > > > + We have new chips support out-of-the-box for free. > > > > > > > > > > > > Cons: > > > > > > - All ESP implementation in NuttX depends completely on external > > > > > > source that may disappear one day. > > > > > > - If we freeze esp-sdk then we loose updates, features, and > vendor > > > > > > maintenance. > > > > > > - We won't be able to cope with amount of changes in esp-sdk on > our > > > > own. > > > > > > > > > > > > This situation is not perfect from NuttX point of view but > optimal > > > > > > from Espressif point of view, and provides working up-to-date > > > > > > environment for NuttX ESP32* users. We have really good support > > from > > > > > > Espressif, unlike any other vendor. Any big company has its goals > > and > > > > > > rules that we have no choice to follow, and there are other chips > > > that > > > > > > require some binary blobs too. > > > > > > > > > > > > I am not sure if we can do anything about it.. unless you want to > > > > > > start your own fully open-source esp-sdk? It would be perfect to > > have > > > > > > fully open-source radio stacks but its astronomical amount of > work. > > > > > > > > > > > > The simplest solution to a stalled PR is just asking our > community > > to > > > > > > keep pushing until its processed :-) > > > > > > > > > > > > -- > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > > > > > > > On Wed, Aug 5, 2026 at 12:21 AM Felipe Moura Oliveira > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > I would like to raise a concern about NuttX’s dependency on > > > > Espressif’s > > > > > > > esp-hal-3rdparty < > https://github.com/espressif/esp-hal-3rdparty> > > > > > > repository > > > > > > > and discuss whether there is a way to give the NuttX community > > more > > > > > > control > > > > > > > over the changes required for its development. > > > > > > > > > > > > > > The repository is publicly available, but it is maintained and > > > > > controlled > > > > > > > by a single private company. As a result, external > contributions > > > are > > > > > > > handled according to that company’s internal priorities and > > > > > availability, > > > > > > > which can make it difficult for the NuttX community to address > > > issues > > > > > > that > > > > > > > block our own development. > > > > > > > > > > > > > > As a concrete example, I opened espressif/esp-hal-3rdparty#13 > > > > > > > <https://github.com/espressif/esp-hal-3rdparty/pull/13>, it > has > > > been > > > > > > open > > > > > > > for 28 days. It is a small change consisting of one commit and > 15 > > > > added > > > > > > > lines across two header files—six lines in one file and nine in > > the > > > > > > other. > > > > > > > The PR has been acknowledged, but it has not received a > technical > > > > > review, > > > > > > > and there is no expected completion date. > > > > > > > > > > > > > > I understand that the Espressif maintainers have other > > priorities, > > > > and > > > > > > this > > > > > > > is not intended as criticism of the individuals involved. > > However, > > > I > > > > > > > believe it illustrates a governance problem for NuttX: changes > > > > required > > > > > > to > > > > > > > support NuttX on specific hardware may depend on a repository > > whose > > > > > > review > > > > > > > process and priorities are outside the control of our > community. > > > > > > > > > > > > > > My experience while porting Dropbear < > > > > https://github.com/mkj/dropbear> > > > > > > was > > > > > > > quite different. We encountered some problems during the port, > > but > > > > its > > > > > > > maintainer actively helped by reviewing the code, suggesting > > > changes, > > > > > and > > > > > > > quickly accepting the corresponding upstream pull requests. > > > > > > > > > > > > > > I would therefore like to ask whether it would be possible to > > > > maintain > > > > > a > > > > > > > fork of esp-hal-3rdparty under the Apache/NuttX umbrella, with > > > > > > appropriate > > > > > > > NuttX committers having write access. Such a fork could > continue > > > > > tracking > > > > > > > Espressif’s upstream repository, and generally useful changes > > could > > > > > still > > > > > > > be submitted upstream whenever possible. > > > > > > > > > > > > > > If maintaining a repository under Apache is not feasible or > > > > > > > appropriate, another > > > > > > > suggestion I have is to start building our own HAL and via > > kconfig > > > > > select > > > > > > > between the internal driver or the 3rd-party. If you have other > > > > > > > suggestions, please let's talk about them. > > > > > > > > > > > > > > > > > > > > > > > > > > > > *--Felipe Moura de Oliveira* > > > > > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0 > > > > > > > > > > > > > > > > > > > > > > >
