ESP8266 Community Forum

- Sun Jan 17, 2016 9:09 am #39044 That certainly looks like it. _P is very well-known from Atmel microcontrollers.

The problem with such constructions is that whatever is in flash, you can never handle as a string. So in the sendContent_P function there must be some code to copy the string from flash to ram, in the end.

So that's why I suggest to use something that keeps some "flash" strings in memory and when done, the ram can be used for another string, so you end up using just a tiny bit of ram, compared to copying all strings from flash to ram, what happens now.

- Wed Jan 20, 2016 9:36 am #39297 I am thinking of the following (now it appears my dram is shrinking rapidly lately):

- I have a wrapper function snprintf that calls ets_vsnprintf (I think snprintf is way more useful than vsnprintf)
- I'll add a wrapper, something like snprintf_flash, that will copy the format string to dram temporarily and then call ets_vsnprintf
- when ets_vsnprintf returns, the dram space for the format string can be released or reused
- add an additional region in the linker script that follows the irom0_0_seg segment, e.g. flash_data_seg
- make the format strings go to a new section (e.g. .flash.rodata) that is placed into the flash_data_seg (add __attr__((section(".flash.rodata))), I guess that should work) + add a #define, something like "rodata".
- that way most my strings will be virtually in flash without too much hassle
- maybe a dedicted wrapper for str(l/n)cpy could be added as well, to save even more dram

- Wed Jan 20, 2016 3:21 pm #39311 Fixed, exactly like above

Already cleaned up 600 bytes from dram by applying this to just one (large...) format string, great.

- Mon Feb 15, 2016 12:23 pm #41182 Now replaced almost all string constants and saved up to 20 kbytes!