Did I ask this question before? Is there a workaround?
For a reason unknown to me the compiler generates a copy of the array into RAM, even for const.
PROGMEM does not help for ESP8266, because it is defined empty (btw pgmspace.h is not in <avr/pgmspace.h> for ESP8266, also a nuisance of this package).
I know that early compilers intentionally produced this copy into RAM for string literals, to allow modification, but with explicit const declaration this copy is unexpected.
My question:
is there a workaround to avoid this RAM usage?
ZinggJM:
PROGMEM does not help for ESP8266, because it is defined empty (btw pgmspace.h is not in <avr/pgmspace.h> for ESP8266, also a nuisance of this package).
Are you sure? PROGMEM is defined if the build define ets is used. When I compiled something with "Board: Generic ESP8266 Module" ets was indeed used.
As an aside, here is a pertinent document from Espressif outlining how PROGMEM may be used to save RAM on the ESP8266 when using the Arduino IDE.
Thank you for the answer. Now I know where to look further.
I saw this ets in pgmspace.h, but don't know what it is used for; maybe for real-time os support?
I compile for Wemos D1 mini, and RAM size is an issue with e-paper support (SPI e-papers).
ZinggJM:
I compile for Wemos D1 mini, and RAM size is an issue with e-paper support (SPI e-papers).
When I compile for the "WeMos D1 R2 & mini" the flag is there too. Not sure what is wrong in your case. Have you checked that you have the latest version of the board definition?
ZinggJM:
I saw this ets in pgmspace.h, but don't know what it is used for; maybe for real-time os support?
I don't know what it stands for, but it just seems to be used for the program space definitions.
bash-4.3$ grep -r __ets__ esp8266/
esp8266/hardware/esp8266/2.3.0/platform.txt:compiler.cpreprocessor.flags=-D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ "-I{compiler.sdk.path}/include" "-I{compiler.sdk.path}/lwip/include" "-I{build.path}/core"
esp8266/hardware/esp8266/2.3.0/tools/sdk/lwip/src/Makefile:BUILD_DEFINES = -D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ -DLWIP_OPEN_SRC
esp8266/hardware/esp8266/2.3.0/cores/esp8266/pgmspace.h:#ifdef __ets__
esp8266/hardware/esp8266/2.3.0/cores/esp8266/pgmspace.h:#else //__ets__
esp8266/hardware/esp8266/2.3.0/cores/esp8266/pgmspace.h:#endif // __ets__
esp8266/hardware/esp8266/2.3.0/cores/esp8266/pgmspace.h:#ifdef __ets__
esp8266/hardware/esp8266/2.3.0/cores/esp8266/pgmspace.h:#else //__ets__
esp8266/hardware/esp8266/2.3.0/cores/esp8266/pgmspace.h:#endif //__ets__
Thank you again for the answer. I was wrong, PROGMEM is defined, and helps preserve RAM usage on ESP8266.
I have not yet looked at the espressif document, but looking at the pgm_read_byte macro makes the reason for the original question clear: access to flash memory must be 32bit aligned.
I hope I will never forget this important information, and I will change my code to use PROGMEM and pgm_read_byte for ESP8266 also.
So, in fact, pgmspace.h should really be in the standard include directory, not in .avr, but this would imply too many changes.
ZinggJM:
So, in fact, pgmspace.h should really be in the standard include directory, not in .avr, but this would imply too many changes.
Why would it? When AVRlibc was being written, all of the stuff that dealt with AVR specific registers, like EEPROM, Flash memory, sleeping, power reduction, IO pins, etc. were put in the avr subdirectory. Only stuff that was truly general (like math, strings, stdio, etc) was not put in a subdirectory.
The ESP devices use an Xtensa core designed by Tensilica. It is not an AVR. Espressif chose to mimic the AVR's arrangement for their standard library files. They could have chosen differently. They have no control over AVRlibc and AVRlibc has no control over them. Just because these two architectures stand side-to-side in the Arduino ecosystem doesn't mean their obligated to change to fit each other.
I partly agree.
But look at some other packages, e.g. the multiple packages for STM32.
They have a avr include subdirectory, just to provide a pgmspace.h, because many libraries and examples unconditionally include this header file.
The creators of the ESP8266 package chose differently, and I can also understand this.
So we just must live with the fact that this file must be included conditionally with different include statement.
Neither STM32 or ESP are officially supported by Arduino, so everything is up to the whim of whoever is arranging the tools in their custom core package.
Jiggy-Ninja:
Neither STM32 or ESP are officially supported by Arduino, so everything is up to the whim of whoever is arranging the tools in their custom core package.
Is this true?
I thought all packages directly installable with the Board Manager are officially supported by Arduino. Not all of them are AVR.
There is even a STM32 "by Arduino", named STAR OTTO, which is yet another story.
I like all the excellent work available through the Arduino ecosystem, even those with their own whim (I had to look up this word).
Thank you all!