- Fri May 05, 2023 3:30 am
#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.
. 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.
. So I think I'll need to go back through my code and use the C99 PRIxxx format specifiers to make it platform independent
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.
