How to know the number of bytes and their address that are used up in EEPROM?

Firmware
1

Hi,

I am using Spark Core:

  1. How do I know the number of bytes & their address that are used up in EEPROM when the below struct is saved ?

  2. Is there a method to update just one of the variables of the below struct in EEPROM ?

    struct MyObject{
    String day;
    int week;
    };

    MyObject myObj;

    myObj.day = “Mon”;
    myObj.week = 1;
    EEPROM.put(1, myObj); // saving values to EEPROM

2

you could used a fixed width variable and know exactly how big:


struct MyObject{
  int day;
  int week;
};

MyObject myObj;

const char* verboseDay[8] = {NULL, "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"};

void setup()
{
  Serial.begin(9600);
  myObj.day = 2;
  myObj.week = 1;
  EEPROM.put(1, myObj); // saving values to EEPROM
  Serial.print(verboseDay[myObj.day]);
  Serial.print(", ");
  Serial.println(myObj.week);
}

void loop() 
{

}

there doesn’t seem to be an equivalent of EEPROM.update() for an object other than a byte…

1 Like
3

To know the size of your struct (or any other variable) you can use the the sizeof() keyword.
But I’d not use a String object in such a struct anyway, rather use something like char[4] which would always be four byte, and even better use numbers rather than strings (as @BulldogLowell suggested).

Following a rather rough info about the inner workings of the EEPROM library:
The thing with EEPROM - which actually is flash memory here - is that you can not really modify the contents as you would with RAM or a real EEPROM but you can only reset (LOW) bits individually but can’t set (HIGH) them individually (I think it’s this direction, otherwise just invert the whole lot ;-))
So once you’ve got a bit reset, you can only wipe the whole page (set all the bits HIGH in that page) and reset the needed bits again.
Since flash memory gets worn out when you do a lot of page clear cycles the Particle EEPROM library uses some wear leveling by moving a 100 byte window across different hardware locations in a bigger area to avoid page erases for each single bit change.
For that reason there is no use in actually knowing the raw hardware location of your last stored byte, since this exact location will usually not be the location for the next write instruction.

Some (old) discussion about the introduction of EEPROM library here
EEPROM / FLASH access library