I’m storing CRGB color patterns in arrays, and using memcpy8 to display them. Works fine, but I’m running out of dynamic memory, and would like to use PROGMEM to store them in program storage space. Could someone please help me work out the code to enable FASTLED_USE_PROGMEM?
I posted an example at: https://gist.github.com/SpinKix/c2b5bcfd4e98a81addb7
Thanks
FASTLED_USE_PROGMEM is just an internal flag.
To store your data in progmem, just follow ‘regular’ directions for moving data / arrays to progmem in regular Arduino documentation, e.g., http://playground.arduino.cc/Main/PROGMEM Although to be honest, that’s not the clearest document.
There are several tutorials around the web for moving static data to progmem; I don’t have a favorite myself or I’d link to one.
I did give it a shot for quite a few hours previously with no success.
Managed to store arrays in flash, but kept having compile errors when I retrieved them.
With more digging, FASTLED_USE_PROGMEM looked like a way.
Now that you’ve pointed me in the right direction, I’ll keep at it.
This time last year I didn’t even know what an Arduino was, but thanks to everyone here, I’m making progress.
Thanks so much!
Just make sure you arrays are declared outside of any functions and add the keyword ‘const’ before the datatype. e.g.,
const uint8_t SpriteData[] = { … };
Thanks Aaron.
Looks like the problem is PROGMEM’s type limitations.
Since I was storing CRGB colors, the CRGB type wasn’t allowed.
The CRGB colors will store with PROGMEM, but reading throws type errors.
If I read the CRGB colors as byte, word, or long PROGMEM works, but then CRGB colors are wrong.
Guessing it’s because CRGB stores three bytes in succession.
Maybe casting to CRGB? (Above my abilities now.)
Workaround was to store an array of integers used as pointers to remap the LED array order, fill the beginning with colors, then black for the rest.
Can’t use memcpy. Slower, but bonus is ability to control the colors.
In the past, I’ve used uint32_t for storing colors in PROGMEM. It takes 4 bytes each (vs 3), but it then lets you construct a CRGB directly from the uint32_t.