Discuss here different C compiler set ups, and compiling executables for the ESP8266

User avatar
By eriksl
#96332 You have some interesting challenges there ;). A lot of them I won't experience (because I don't use the corresponding functionality) but a few I have experience with.

To begin with, the int != int32_t has been a known issue for a long time. The Espressif header files really suck, all types are wrong. I think with newer GCC's the default warning/error levels have changed and you're into that, because I have been getting this for ages already. The only solution (and I do this) is to maintain your own versions of the header files. The only drawback is that in theory a definition might change at some time and you'd need to change your own version. But I haven't seen this for a very long time. Also the original header files are overflowing with #define statements which is both ugly and wrong, these should be either enums or static consts, in same rare cases an inline function.

I've been doing without libc for absolutely years, but now I have it added again. I am using very little of it, it's mostly for the snprintf version that includes floats. I did tweak some options of newlibc though which make it use considerately less RAM.

As for lwip I can really recommend to compile your own version anyway. That way you can tweak all sorts of options which can make it use far less memory than default. Not everybody needs e.g. 16 sockets and ip defragmentation (not tcp segmentation). You get also the opportunity to make lwip run in a piece of pre-allocated memory (which can come from a static variable instead of malloc()), which makes the amount of used memory much more predictable, very little chance of suddenly running out of memory.

I don't recognise the amount or IRAM vanishing when upgrading GCC or newlib. This may come from my construction where all of the object files and libraries (besides a few, like libpp) are automatically forced to have FLASH region linkage. This also saves me from adding an exception to each and each function, everything goes into FLASH by default, only functions explicitly marked as "iram" go into IRAM. There are just a few, like two ISR's and a few functions that get called very frequently (like 100 times a second...) or I2C code that is best executed without interruption (although I2C is asynchronous).

My source code / project has everything included nowadays. If not already fetched and built it will do so for the toolchain, the SDK and LWIP, so everything is build from scratch, only the closed source parts are linked as-is. If one has a Linux environment with same basic build tools, one can do a git clone, "make" and then just wait ;-) For die-hard SDK-users it may not be very familiar though, because I got rid of the standard Espressif project layout and Makefile, imho it's ugly and limiting. The guys at Espressif are brilliant at hardware engineering, but they're clearly not experienced software engineers.
User avatar
By eriksl
davydnorris wrote:Bit more progress but still not close:
- found that almost all the missing functions have been moved out into libgloss or libnosys, so you need to add nosys to your list of libs

Haven't seen that (yet).

davydnorris wrote:Bit more progress but still not close:
- still trying to get --specs=nonsys.specs to work properly. Does anybody know how it should be used? I thought you just added it to the link line and it automatically added -lnonsys and the nano versions of the libraries but it seems to not do anything

What do you exacly mean with the "nano versions"? Aren't you using newlib?

- __ctype_ptr__ error is actually caused by liblwip being compiled with an old GCC version so I'll have to make or find a newer version of that

I remember having this issue as well, I had my implementation of ctype for this, but now it doesn't seem to be required anymore. Maybe it's indeed the lwip stuff.

I used to compile with irom versions of the libraries, so I tried to flip my build back to my old working toolchain to compare sizes and now all the sprintf formatting changes I made make it not compile :-(. So I think I'll need to go back through my code and use the C99 PRIxxx format specifiers to make it platform independent

That's interesting? What did you do exactly, the sprintf formatting specifiers have been the same for a very long time. You may want to workaround it by not changing the formatting specifiers and casting the ints to a "well-known" type like int or unsigned int. Or just change the error into a warning.

I am still very glad I am using my own building environment. No silly python or cmake :o and it just works. Now if only Espressif would open op all code that's not illegal to share (i.e. the wlan stuff), I would have absolutely no reason to ever switch to ESP32. It's a great MCU but everything it can do, I can do with an ESP8266 already with some extra code here and there. If Espressif would every release a version of the ESP32 that is easily to use for hobbyists (i.e. it has hand solder pitches, at least 1 mm, like the ESP12 and no useless pins broken out) and that comes with no SDK at all, just a manual how to program everything (i.e. all hardware specs) then I'd the first to switch. But it's not going to happen.
User avatar
By davydnorris
#96347 @eriksl - if I bundled up my toolchain as a zip, would you try it on your code? Would love to see if it works on something that doesn't use a lot of the libraries

Will comment on your other posts a bit later (thanks so much for the input BTW!)
User avatar
By eriksl
#96350 I will first try something else. The same thing I did earlier on and that's simply updating the crosstool-ng repo and fired it up. Great chance it will work out of the box with a newer GCC version.