Fastled: Gradient palettes get stored in RAM on ESP8266

[Aircoookie]

Hello!
I've noticed that if I use the following syntax to define a palette:

DEFINE_GRADIENT_PALETTE( heatmap_gp ) {
  0,     0,  0,  0,   //black
128,   255,  0,  0,   //red
224,   255,255,  0,   //bright yellow
255,   255,255,255 }; //full white

the palette gets stored in RAM, not PROGMEM, even though the docs say so.

In platforms/esp/8266/led_sysdefs_esp8266.h I found this definition:

// Default to NOT using PROGMEM here
#ifndef FASTLED_USE_PROGMEM
# define FASTLED_USE_PROGMEM 0
#endif

I have some ~2kB worth of palette definitions in my application and would like to free up some memory.
Can someone explain the issue of enabling PROGMEM on ESP8266?

[kriegsman]

Thank you for pointing this out; I think it’s probably just an oversight and something we can change easily. I’ll take a look later today if I can.

[Aircoookie]

Thanks for your quick response! I just tried # define FASTLED_USE_PROGMEM 1 in my sketch.
Unfortunately, it seems like the default of disabling it for esp8266 was in fact intentional.
It compiles just fine and reduces the memory usage as expected, but as soon as a palette stored in PROGMEN is selected, the application crashes (using latest 2.5.0 esp8266 core and FastLED 2.3.6):

Exception 9: LoadStoreAlignmentCause: Load or store to an unaligned address
Decoding 10 results
0x402080b6: CRGBPalette16::operator=(unsigned char const*) at C:\Users\cschwinne\Documents\Arduino\libraries\FastLED/colorutils.h line 836
0x40269a7d: lwip_init at ?? line ?
0x4020966a: WS2812FX::handle_palette() at C:\Users\CSCHWI~1\AppData\Local\Temp\arduino_build_5212\sketch/WS2812FX_fcn.cpp line 699
0x40100370: millis at C:\Users\cschwinne\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.0\cores\esp8266/core_esp8266_wiring.c line 183
0x40100370: millis at C:\Users\cschwinne\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.0\cores\esp8266/core_esp8266_wiring.c line 183
0x40100370: millis at C:\Users\cschwinne\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.0\cores\esp8266/core_esp8266_wiring.c line 183
0x402096e3: WS2812FX::service() at C:\Users\CSCHWI~1\AppData\Local\Temp\arduino_build_5212\sketch/WS2812FX_fcn.cpp line 66
0x40219c26: loop at C:\Users\cschwinne\git\Arduino\WLED02\wled00/wled00.ino line 560
0x4022f524: loop_wrapper() at C:\Users\cschwinne\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.0\cores\esp8266/core_esp8266_main.cpp line 125
0x40100ea5: cont_wrapper at C:\Users\cschwinne\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.0\cores\esp8266/cont.S line 81

Maybe I can try it again later with a simple palette example sketch to verify it's not an issue with my rather complex application.

Edit: With just pasting the gradient palette definition in the example ColorPalette.ino and referencing it in one of the if statements in ChangePalettePeriodically() , the issue doesn't occur. So it's likely there is some interference with EEPROM, WiFi or other libs...

[Aircoookie]

Alright, didn't know why ColorPalette.ino worked just then. Here is a minimal example where the issue occurs, without using WiFi libs or anything.
PaletteProgmemTest.zip

By the way, I don't need a solution quickly, so take your time, just making you aware of it :)

[kriegsman]

ESP microcontrollers requires 4-byte-aligned reads from PROGMEM; AVR do not. I'm pretty sure that when we first ported to ESP, I said "oh well, I'll just stick it in RAM for now, and come back to deal with the specifics of ESP's needs about PROGMEM later." Now, it appears, is 'later'.