No here too. ESP-SDK is developed by Vendor, people who know what to do and why. There are many tricks used there probably that cannot be easily automatically converted. There will be zero guarantee for the result. We will switch from something bad to really bad. And you would have to rewrite everything each time the source SDK is updated which seems a guarantee for a catastrophe in the long term. Also we would depend not only on the source SDK but also external AI tools that are commercial and we have zero control of.
We need to think long-term. Situation here is far from perfect but optimal. We do not want to change it into anything worse. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Wed, Aug 5, 2026 at 3:26 PM 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> > > > > > > > > >
