Closed d-a-v closed 3 years ago
Thanks again!
I think you laid bare a more fundamental issue: those variables don't need to be static at all! Looking back I think I've made them static either because I had different plans for portal() or to be lazy and capture them implicitly for the lambdas.
With static pointers and then creating the objects at runtime, basically the objects themselves are no longer static and the only remaining use for static
is a hack to save a tiny bit of code down the road (they can be excluded from the lamda captures).
I'll just turn these variables into regular function scoped variables, which should have the same effect as your PR plus a few more bytes for the pointers :P
As an aside, I get much smaller numbers for the Advanced.ino example (changed to use LittleFS),
IROM : 301532 - code in flash (default or ICACHE_FLASH_ATTR)
IRAM : 27424 / 32768 - code in IRAM (ICACHE_RAM_ATTR, ISRs...)
DATA : 1256 ) - initialized variables (global, static) in RAM/HEAP
RODATA : 1992 ) / 81920 - constants (global, static) in RAM/HEAP
BSS : 25696 ) - zeroed variables (global, static) in RAM/HEAP
PR #12:
IROM : 301244 - code in flash (default or ICACHE_FLASH_ATTR)
IRAM : 27424 / 32768 - code in IRAM (ICACHE_RAM_ATTR, ISRs...)
DATA : 1256 ) - initialized variables (global, static) in RAM/HEAP
RODATA : 1992 ) / 81920 - constants (global, static) in RAM/HEAP
BSS : 25408 ) - zeroed variables (global, static) in RAM/HEAP
captures:
IROM : 301324 - code in flash (default or ICACHE_FLASH_ATTR)
IRAM : 27424 / 32768 - code in IRAM (ICACHE_RAM_ATTR, ISRs...)
DATA : 1252 ) - initialized variables (global, static) in RAM/HEAP
RODATA : 1992 ) / 81920 - constants (global, static) in RAM/HEAP
BSS : 25400 ) - zeroed variables (global, static) in RAM/HEAP
So if you're looking to save RAM, it may be useful to find out what's causing this difference. I'm using esp8266 board package version 2.7.4.
A thought: for RAM savings, it might be interesting to allow putting the settings in a lambda, and call that once at startup and once when loading the portal, and dump the params vector in between. Especially those description strings can be large.
Update: hm, on the other hand, if you need that much RAM and also still need the portal, then you may run into issues when starting the portal if you haven't freed the memory yet. Reserving it may make sense. Food for thought...
Released as v3.5.4
Thanks !
Compilation results of 'Advanced' example on esp8266:
Before:
After: