Has anyone tried storing CRGB values in EEPROM? If I use the CRGB struct then I get 0,0,0 after a read, but if I use a uint32_t in the structs instead then it returns the value correctly.
Ex:
typedef struct {
CRGB color;
CRGB correction;
} Settings;
EEMEM Settings foo = {
CRGB(255,0,0),
TypicalSMD5050
};
Note: the settings are stored by uploading a .eep file using avrdude
If it matters I am using eeprom_read_block to pull the struct out of the EEPROM. The example is a dummy struct, but my real one has multiple fields of various primitive types that all load fine. It is only the CRGB that fails to load, so I am fairly confident it is not the way I am retreiving it.
Interesting! I haven’t tried using EEMEM myself-- but I frequently store data in EEPROM using the explicit API calls (and of course, that works fine).
If I get a chance I’ll take a look at the EEMEM interaction.
Oh, huh. I wonder if it’s the fact that CRGB isn’t itself a primitive type, but a class with a ctor etc.
Does it work for you with other structures / classes, or just primitive types?
Strange. If I edit the SRAM copy of my struct then store it using eeprom_write_block then it gets loaded correctly through resets. It appears that it is just the initial value stored in the .eep is incorrect. I have not tried any other structs/classes yet as this primarily an led project 
Did a little bit of inspection. Looking at the generated .eep file it appears each color is 0x000000 which is then uploaded to the EEPROM. So for some reason gcc/g++ is not generating the struct correctly. If it helps this is the file format the .eep uses - https://en.wikipedia.org/wiki/Intel_HEX.
EDIT: I manually edited the bytes in the eep file and the colors are loaded and shown correctly. So it is definitely just the files generation that is screwy.
Interesting. Looks like static initialization of the CRGB isn’t done at compile time?
That’s what it appears like. Even if I do something like 0xFF0000 it fails if the type in the struct is CRGB. As mentioned before changing the type to uint32_t fixes it. I would try to make it a const but I can’t change the struct definition as I want create an in ram copy at the start of the program than can then be edited and rewritten to the eeprom.
Yeah - because CRGB has a constructor it will be initialized at run, not compile time.
However, since it’s structure is simple - you can set it up as just a 3 byte array in your generation - and the. The loading code can just treat it as a CRGB
uint8_t rgb[3] = {255,128,0};
@Daniel_Garcia sadly that didn’t seem to work when I tested it last night. Maybe making it a separate variable is the key (I was doing nested brackets/initialization)
I had similar problems and ended up working around it by building CRGB objects after fact from 3 byte storage aligned with RGB.
Certainly not the most elegant solution but it works.
Perhaps this:
struct {
…
uint8_t Color1Red;
uint8_t Color1Green;
uint8_t Color1Blue;
…
And then cast like this (assuming ‘s’ is one of these structs) :
CRGB* Color1ptr = (CRGB*)(&(s.Color1Red));
Basically, define it as three one byte fields, but then later make a pointer to that and treat it like a CRGB*. Maybe?
Thanks for the suggestions guys. Something like Mark/Jarrod said would work, I just wish I could store it as a CRGB so I could use s.color in my code without having to do casts everywhere.
I have actually hacked together a IntelHex formatted .eep builder that is now used in my build scripts. This way I can choose what exactly is stored in the eeprom. It’s probably a little overkill for this application, but I figure it could be used some form of graphical settings editor for users in the future.
I didn’t end up using casts.
I made a helper function that pulled any pertinent EEPROM locations to local or global CRGB objects as necessary.
Ran it in setup{} and when explicitly necessary to alter the currently displayed colors.
Thereagain, my EEPROM usage was for static “images” or for defining a color function so nothing too intensive on the memory front.
If you’re going to pull colors directly from EEPROM while in an animation my method probably wouldn’t be the most efficient 
I actually don’t have addressable led strips yet, I am just using FastLED for most of it’s math (HSV, corrections, etc). So with only a few colors that method may work well.