EEPROM and storing 24bit color

Status
Not open for further replies.

nekidfrog

Active member
I'm currently using the EEPROMex library to store Longs in eeprom. However even with 4k eeprom on the bigger chips I will run out of space quickly storing user color codes. So comes my conundrum of storing data. uint32_t and longs are 32bit variables but I only need 24bits of that... with the EEPROMex library I can tell it where to start and usually with 32bit values I space them 4 bytes apart.. When I store the long does it auto generate 4 bytes ? or only as many bytes as the value itself? aka would it store a 0xFF000000 if I told it to store 0x000000? or would it only use 3 bytes of the 4 bytes needed? and thus I could tell the eepromex library to only count 3 bytes apart saving me a huge chunk of space!

TLDR when creating variables does it store the entire byte size of the variable or only the actual byte value used of said variable?
example create a long and assign it 0xFF.. would the long be 1 byte big? or would it still be 4 bytes big just with crap??
 
Well tried and while some works getting corruption on last variable in the array somehow and every once in awhile it doesn't update correctly.. but that may be due to the way the eepromex library's updateLong function works.
 
I would be astonished if writing to EEPROM was inspecting the value to be stored to see if it could remove some bytes that were all zeroes. It will be writing the full size of the type.

Is the EEPROMex library restricted to 32bit types? To store colours you could have three uint8_t values for example.
 
I could split the 24bit color into it's R/G/B counterparts, however with the amount of color I have to store, it makes it a huge headache to keep track of 3 address's per color than 1 address. I'm storing 8, 10 frame 4x4 color matrix's that is user programmable.

If I stored it as 3 8bit colors I could drop it from 5120 to 3840 which could be done within a 4k eeprom... I might need to do just that then. Ugh means data management is going to be a pain in eeprom. I'm going to have to manage 3840 addresses.... for a single user built animation.
 
Well I broke down and decided to code the framework for breaking the 24bit hex down into it's RGB and storing those and rebuilding back to 24bit when used in the color array.
 
Ok, I'm getting royally confused at this point.. So I pass my 32bit color from processing to the arduino fine. I disassemble the 24bit color hex into it's separate rgb bytes and properly store it in EEPROM. After a restart I have it pull data from eeprom and reconstuct the 24bit hex and put it back into the array for quick use....

My problem is the reconstruction of the 3 bytes back into the 24bit hex...
uint32_t color = (r << 16) | (g << 8) | b; <-- this should take my 0, 255, 0 values and give me 0xFF00 or 0x00FF00, or 0x0000FF00 depending on how you want to read it... yet instead it's giving me this

0xFFFFFF00

I have it printing out the R G B values to verify they are indeed 0, 255, 0 and they are. But the above conversion is not working correctly. Please help a newbie out in bit shifting...
I've since masked it off with & 0xFFFFFF and that's removed the upper 24th bit but my Red value even tho it's listed as 0 is coming up 255 ...... GRRR

Code:
uint32_t construct(byte r, byte g, byte b){
	Serial.print("red: ");
	Serial.println(r);
	Serial.print("green: ");	
	Serial.println(g);
	Serial.print("blue: ");	
	Serial.println(b);
	uint32_t color = (((r << 16) & 0xFFFFFF) | ((g << 8) & 0xFFFFFF) | b & 0xFFFFFF);
	Serial.println(color, HEX);
	return color;
}
 
Last edited:
I just ran this on a Teensy3. Seems to work fine.

Code:
void setup()
{
  Serial.begin(9600);
}

void loop()
{
  byte r = 128;
  byte g = 255;
  byte b = 1;
  unsigned long color = (r << 16) | (g << 8) | b;
  Serial.print("color = ");
  Serial.println(color, HEX);
  delay(1000);
}
 
... yet instead it's giving me this

0xFFFFFF00

If you want useful help, you must post (hopefully) concise but complete code that demonstrates the problem. Without seeing the actual code you're running, and also knowing which hardware you're using, how can you expect anyone to give you a useful answer?
 
On a Teensy2, you need to type cast to (unsigned long), because the compiler defaults to 16 bit signed int.

Do it like this:

Code:
void setup()
{
  Serial.begin(9600);
}

void loop()
{
  byte r = 128;
  byte g = 255;
  byte b = 1;
  unsigned long color = ((unsigned long)r << 16) | ((unsigned long)g << 8) | b;
  Serial.print("color = ");
  Serial.println(color, HEX);
  delay(1000);
}

Next time, start by posting specific code and mention which hardware you are using. It really does help!
 
Well I'll be damn! I tried using 16L before but that didn't work which I assumed was the same but I guess not.

Does it have to be unsigned long? or can I substitute uint32_t ?
 
Status
Not open for further replies.
Back
Top