Sketch size and memory usage after #5376 commit #5423
Comments
…in (#5376) * Move to PROGMEM aware libc, allow PSTR in printf() A Newlib (libc) patch is in progress to move the _P functions from inside Arduino into first-class citizens in libc. This Arduino patch cleans up code that's been migrated there. Binaries for the new libs are included because it seems they're part of the Arduino git tree, and should be replaced with @igrr built ones when/if the Newlib changes are accepted. Notable changes/additions for Arduino: Allow for use of PROGMEM based format and parameter strings in all *printf functions. No need for copying PSTR()s into RAM before printing them out (transparently saves heap space when using _P functions) and makes it easier to print out constant strings for applications. Add "%S" (capital-S) format that I've been told, but cannot verify, is used in Arduino to specify a PROGMEM string parameter in printfs, as an alias for "%s" since plain "%s" can now handle PROGMEM. Optimized the memcpy_P, strnlen_P, and strncpy_P functions to use 32-bit direct reads whenver possible (source and dest alignment mediated), but there is still room for improvement in others. Finally, move several constant arrays from RODATA into PROGMEM and update their accessors. Among these are the ctype array, ~260 bytes, mprec* arrays, ~300 bytes, and strings/daycounts in the time formatting functions, ~200 bytes. All told, sketches will see from 300 to 800 additional RAM heap free on startup (depending on their use of these routines). * Fix merge error in #ifdef/#endif * Fix host test using the newlib generic pgmspace.h Host tests now use the sys/pgmspace.h for compiles instead of the ESP8266-specific version. * Update with rebuilt libraries using latest newlib * Include binaries built directly from @igrr repo Rebuild the binaries using a git clone of https://github.com/igrr/newlib-xtensa Build commands for posterity: ```` rm -rf ./xtensa-lx106-elf/ ./configure --prefix=<DIR>/esp8266/tools/sdk/libc --with-newlib \ --enable-multilib --disable-newlib-io-c99-formats \ --disable-newlib-supplied-syscalls \ --enable-newlib-nano-formatted-io --enable-newlib-reent-small \ --enable-target-optspace \ --program-transform-name="s&^&xtensa-lx106-elf-&" \ --disable-option-checking --with-target-subdir=xtensa-lx106-elf \ --target=xtensa-lx106-elf rm -f etc/config.cache CROSS_CFLAGS="-fno-omit-frame-pointer -DSIGNAL_PROVIDED -DABORT_PROVIDED"\ " -DMALLOC_PROVIDED" \ PATH=<DIR>/esp8266/tools/xtensa-lx106-elf/bin/:$PATH \ make all install ```` * Fix merge define conflict in c_types.h * Fix strlen_P misaligned source error Include fix from newlib-xtensa/fix-strlen branch cleaning up misaligned access on a non-aligned source string. * Fix strlen_P and strcpy_P edge cases Ran the included test suite on ESP8266 tstring.c with the following defines: #define MAX_1 50 #define memcmp memcmp_P #define memcpy memcpy_P #define memmem memmem_P #define memchr memchr_P #define strcat strcat_P #define strncat strncat_P #define strcpy strcpy_P #define strlen strlen_P #define strnlen strnlen_P #define strcmp strcmp_P #define strncmp strncmp_P Uncovered edge case and return value problems in the optimized versions of the strnlen_P and strncpy_P functions. Corrected. * Fix memcpy_P return value memcpy-1.c test suite showed error in return value of memcpy_P. Correct it. * Fix strnlen_P/strlen_P off-by-4 error Random crashes, often on String constructors using a PSTR, would occur due to the accelerated strnlen_P going past the end of the string. Would make debug builds fail, too (ESP.getVersionString() failure). Fix to fall through to normal copy on a word that's got a 0 byte anywhere in it. * Add device tests for libc functional verification Add test suite used to debug libc optimized _P functions to the device tests. * Rebuild from igrr's repo (same source as prior) Rebuild .a from igrr's repo at 347260af117b4177389e69fd4d04169b11d87a97 * WIP - add exceptions * Fix exception to have 0-terminator * Move some exception constants to TEXT from RODATA * Remove throw stubs * Move more exception stuff to ROM * Enable exceptions in platform.io * Remove atexit, is duplicated in rebuilt lib Need to look at the quick-toolchain options, there seems to be a definition for atexit defined there (libgcc?) that needs to be excised. For now, remove our local do-nothing copy. * Update libgcc to remove soft-fp functions The esp-quick-toolchain generated libgcc.a needed to have the soft-FP routines that are in ROM removed from it. Remove them in the new esp-quick-toolchain and update. * Fix merge typos in Makefile * Add unhandled exception handler to postmortem * Return our atexit() handler * Latest stdc++, minimize exception emercengy area * Remove atexit from newlib atexit was defined in newlib strongly, but we also define a noop atexit in core. Since we never exit, use the core's noop and delete the atexit from libc.a Updated in esp-quick-toolchain as well. * Move __FUNCTION__ static strings to PROGMEM __FUNCTION__ is unlikely to be a timing sensitive variable, so move it to PROGMEM and not RODATA (RAM) using linker magic. asserts() now should take no RAM for any strings. * Clean up linker file, update to latest stdc++ * Update to latest stdc++ which doesn't call strerror * Update to GCC5.1 exception emergency allocator Using GCC 5.1's emergency memory allocator for exceptions, much less space is required in programs which do not use exceptions and when space is allocated it is managed more efficiently. * Initial try with new compiler toolchain * Include newlib built from esp-quick-toolchain * Update JSON with all new esp-quick-toolchain builds * Use 64bit Windows compiler on 64bit Windows * Dump std::exception.what() when possible When doing the panic on unhandled exceptions, try and grab the .what() pointer and dump it as part of the termination info. Makes it easy to see mem errors (std::bad_alloc) or std::runtime_error strings. * Use scripted install from esp-quick-toolchain Makes sure proper libraries and includes are present by using a scripted installation from esp-quick-install instead of a manual one. * Update eqk to remove atexit, fix packaging diff
|
The price for exceptions is supposed to be about 19KB of flash size and about 800 bytes of heap. |
|
@reaper7 can you upgrade the toolchain with |
|
That's a good sketch for stress testing things, @reaper7. Do you just put the libs in ~Arduino/libraries, and build sonoff.ino with any configurations? You will need to update your toolchain (manually rerun tools/get.py) and apply #5425 to get it to build, but I'm seeing an iram explosion in linking that needs looking at before a good binary can appear. |
|
I checked out #5376~1 but using the latest toolchain (i.e. just before the exceptions merge, but exceptions are not enabled in the core/arduino build flags) and can't build w/nodebug/noassert due to IRAM full errors, so I think I'm building a different config than you. That said, I expanded the IRAM linker space (i.e. it won't run, but will give me a binary). Pre-exceptions build usage Post-exceptions build use (I could build normally w/#5425 as long as I did NDEBUG+NASSERT config): So in my build I'm seeing flash usage is up significantly at 150K, RAM is down by ~600 bytes. My guess is that there are |
|
I think I have latest toolchain: I see where is my mistake with RAM...for a long time I have been building with VTables in HEAP, I still have to disable some sonoff modules for ota functionality (sketch size <50%) |
|
Did some looking in generated executable and you've got 87K worth of gcc_except_table + eh_frame (basically the data structure G++ uses to handle exceptions) with this codebase. There's an add'l ~19K of code to actually process those bits on an exception (i.e. This points to the need for exceptions to be user configurable...ugh, but good to catch now! |
|
See #5434 for a menu to disable exceptions completely. |
|
So the default will be disabled exceptions? |
|
Exception support only adds ROM and has ~0 impact on free heap. It catches when you try to do a ROM size will be an issue for some stuck on 512M or 1M flash devices looking to do OTA, I fully understand. The default now is enabledbut if enough users have an issue we can definitely adjust! |
|
Thank you for explanation. ROM size matters for all TASMOTA users ;-) |
|
Closing via #5434 . A word of caution to Tasmota developers, as well as others who are near the 512KB bin size limit: Exceptions are configurable for now, but it is planned to eventually enable them permanently. This is because Exceptions are the only mechanism that allows reacting correctly to error conditions in some cases, e.g.: oom while allocating in construction, oom during concat of Strings, etc. This drastically improves code robustness. As a result, I suggest planning for bin size increase. There are several things you might do to slim down your build result, here are some ideas (without having looked at your code):
|
Basic Infos
Platform
Settings in IDE
Problem Description
what happened with the final sketch size and dynamic memory usage on commit 6280e98?
I try to compile latest sonoff-tasmota for ESP8285; 1M/noSPIFFS;
and on previous commit: 4941711
I getting:
Sketch size: 491564 (48%), max 1023984
Global variables: 50984 (62%), 30936 free for local variables
but with this commit:
Sketch size:575192 (56%), max 1023984
Global variables: 78044 (95%), 3876 free for local variables
and info about low level of available memory (possible stability problem)
MCVE Sketch
sonoff-tasmota sketch
https://github.com/arendst/Sonoff-Tasmota
Debug Messages
The text was updated successfully, but these errors were encountered: