ESP8266 Community Forum

- Tue May 09, 2023 10:40 am #96391

The latest newlib and newlib nano are used with no local patches, only the overlay, which is required for xtensa chips in general. The latest ESP32 risc chips don't use anything - newlib is used straight out of the box

It seems this is already the case for the 2.0.0 version which I am using (from Max Filipov), but I think the overlay is specific for each newlib version and I am really not knowledgeable about how to adjust it for other newlib versions.

If the RTOS-SDK (source) has the overlay, I'd be interested in trying it on my (current) version of crosstool-ng, it will probably just work. IIRC Espressif uses an older version of ctng for their RTOS SDK.

- Tue May 09, 2023 10:48 am #96392

Are you really considering using the RTOS SDK? That means even more Espressif code. Opaque and badly documented as well as badly written. Are you sure? What is the advantage? I have found that using the three (or even one) task queues you can very well do time slicing yourself, for background tasks. Using RTOS means you will have even less direct access to the hardware or CPU.

BTW the integers were always 32 bit (and signed by default), that's dictated by the xtensa platform. The thing you're running into is that more recent gcc compilers are more strictly enforcing the "uint32_t is the same as an unsigned int, but the name is different so it's an error". Which I think is a good thing. Newer gcc's also warn about using a bool as an int and vice versa.

Yes, I've finally given in and am looking to port all my stuff to RTOS based code. The ESP32 chips have some cool features that I want to explore, and hopefully the ESP8266 RTOS will eventually be completely IDF compatible, meaning one code base (or close to) for all chips.

I agree with you on all the above, but the components are all supplied as source - not necessarily good source, but still source, and they are actively maintained by many people now. And a lot of those are people who have been seconded by Espressif and are real coders, such as igrr.

It's not ideal, but I need to be pragmatic, and I need a shorter dev cycle than having to roll my own all the time on a platform they have given up on and refuse to open up

Ok clear. For me I don't have to worry about "production", it's all just hobby and I am still trying to get everything possible out of the ESP8266. IMHO there are still areas to explore there, areas that Espressif is secretive about or supporting software that, even though Espressif refuses to, can be upgraded to a modern version, like lwip, gcc and newlib. I do get the feeling I am becoming the last person to have this interest though

Agree that the ESP32 has some interesting features, but nothing I can't do with the ESP8266. Nice to have hardware I2C and PWM modules, but I just do fine with my software emulations (my I2C implementation can reach speeds of 500 kHz, the Espressif version only 100 kHz; the PWM implementation can reach 18 bit PWM, 16 bits up to 120 Hz, which is not perfect, but better than most hardware implementations).

For me the major ramp is the OTA updates. I am now using rboot, which is really flexible and does everything I need. I am afraid that if I am forced to use the Espressif implementation, I will loose a lot of the flexibility and robustness.

- Tue May 09, 2023 8:43 pm #96396

The latest newlib and newlib nano are used with no local patches, only the overlay, which is required for xtensa chips in general. The latest ESP32 risc chips don't use anything - newlib is used straight out of the box

It seems this is already the case for the 2.0.0 version which I am using (from Max Filipov), but I think the overlay is specific for each newlib version and I am really not knowledgeable about how to adjust it for other newlib versions.

If the RTOS-SDK (source) has the overlay, I'd be interested in trying it on my (current) version of crosstool-ng, it will probably just work. IIRC Espressif uses an older version of ctng for their RTOS SDK.

There's a whole lot of problems with Espressif's prebuilt toolchain, which they include in their download of the RTOS SDK bundle, as well as stand alone. The biggest problem is that it's built on Msys2 with mingw path mapping, and this doesn't work at all when you try to use cygwin. I don't want to install both Msys and cygwin, and I need more unix-like commands than just build tools, so I needed to build the toolchain under cygwin.

The second huge issue is that their toolchain versions are old compared to the latest ESP32 IDF stuff and I want consistent versions of toolchains across all my chip versions (due to the Msys2 builds of the ESP32 chip toolchains I have to rebuild them as well, but that's another story)

I looked hard at the Espressif clone of crosstool-ng - it's originally clones from Max's crosstool-ng repo but they have pulled the latest stuff from the original crosstool-ng repo and it's almost up to date. Ideally they should change their remote to the original source but doesn't really matter. And yes they have their own repos for GCC and newlib, which is really annoying, but it builds.

I went back in their releases and found the last time their repo included any esp8266 stuff and I pulled the samples up to the top, and changed it to be consistent with the ESP32 samples. The esp8266 overlays are all still there and, as far as I can see, they are version agnostic and will work with their current gcc, newlib and binutils.

So now I have built the toolchain, and I pull down the latest RTOS SDK direct from their repo and I have used that to test, and the biggest problem is in the *printf format strings throughout the SDK components. That's going to be a pain to fix, and maybe that's why they have stopped revving the toolchain

- Thu May 11, 2023 12:23 pm #96404 So there really isn't a "grand unified SDK" (the IDF) which Espressif claims?

I hope they went the same road I did: pull the version of crosstool-ng that Fillipov's commits apply to, then merge these commits (so it's a actually an exact copy of what Max has) then <i>rebase</i> it to the current version of crosstool-ng, resolve all the conflicts and then fix stuff and make then neat commits on top. That way you can always do a rebase again. But knowing Espressif, they probably didn't do that and simply merged one large commit with all fixes (well, "fixes"... often) and didn't rebase, so they're for always stuck at that version.

For hobbyists this is OK, but companies really should try to get their adaptations applied upstream, so it's available for everybody and as a free bonus, the upstream will solve any conflicts when upstream gets new versions.

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.

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'd love it so much if we had a few people together, including someone like Max and then make our own, universal build tool chain. Even better if most of the SDK lib's source would be released, then we could also do some cleaning up there. The code from Espressif is really awful. I bet we could save quite some IRAM and DRAM space.