Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradient palettes get stored in RAM on ESP8266 #743

Open
Aircoookie opened this Issue Feb 22, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@Aircoookie
Copy link

Aircoookie commented Feb 22, 2019

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

This comment has been minimized.

Copy link
Contributor

kriegsman commented Feb 22, 2019

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

This comment has been minimized.

Copy link
Author

Aircoookie commented Feb 22, 2019

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

This comment has been minimized.

Copy link
Author

Aircoookie commented Feb 22, 2019

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

This comment has been minimized.

Copy link
Contributor

kriegsman commented Feb 22, 2019

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'.

@kriegsman kriegsman self-assigned this Feb 22, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.