ESP8266 Community Forum

eriksl wrote:In the end it's clear - they don't really want to spend effort on the ESP8266. Especially the NONOS SDK. I think it also clear: the ESP8266 is used by both hobbyists (and they don't care, generate no cash flow) and by companies. It looks like the companies are using it for very simple tasks (like a remote controllable wall socket), for that the current NONOS SDK or RTOS SDK is quite sufficient and if not, the companies can get direct (paid) support from Espressif. So for them, there is no problem. Of course they're trying to get all new projects to move to the ESP32, but I can imagine many companies have a problem with them being more expensive than the ESP8266.

So once in a while I order a stack of ESP12F or ESP12S and hope they will remain available for some time...

I can't disagree with you there I have tried to get them to see that the NonOS SDK is used for an awful lot more than the AT firmware but that's all they think it's for. It served me for a really long time and I'm not excited about trying to move my app to the RTOS but it's now at that point unfortunately.

Another point for me is that I can find developers who have FreeRTOS experience, so the learning curve to come on board and start working on my ideas is shorter.

eriksl wrote:I might have a look at what they did to newlib and incorporate the changes, so I could go to a newer version, but I am really doubting there. There is only very little I am using from libc and the things I use work really well.

Espressif devs posted their newlib version on the newlib mailing list: https://sourceware.org/pipermail/newlib ... 20321.html
I believe that with some persistence they have a chance to get it merged.

eriksl wrote:I also should cleanup some of the GCC patches Max added, as they're for really old GCC versions. Apparently current GCC doesn't need patching for lx106 targets.

I'm not aware of any gcc patches required to generate code for esp8266 that are not in the gcc mainline already. And now with the release of gcc-13 and binutils-2.40 there's even no need in overlay application, core-specific configuration can be entirely external to the toolchain build system. See https://github.com/jcmvbkbc/xtensa-dynconfig

@jcmvbkbc - so glad you joined the thread!

I've got the latest Espressif toolchain building and compiling code for the ESP8266 based on the sample you provided way back, and I get almost all the way through, but my code is almost double the size. If you have any hot tips on where I should start looking I'd be grateful.

Do you think there's a chance Espressif will pull the ESP8266 stuff up into the latest branch and maintain it? I'd really like to be able to have the same versions of everything for both the ESP8266 and the ESP32 chips I'm playing with.

davydnorris wrote:my code is almost double the size. If you have any hot tips on where I should start looking I'd be grateful.

Well, the obvious ones: compare individual object files to see where the excess comes from, see if it's related to optimization options.

davydnorris wrote:Do you think there's a chance Espressif will pull the ESP8266 stuff up into the latest branch and maintain it? I'd really like to be able to have the same versions of everything for both the ESP8266 and the ESP32 chips I'm playing with.

I don't have any inside information and my outside impression is that they're not interested in that, unfortunately.