Writing to the EEPROM

I have a couple of questions about writing to the EEPROM, since my knowledge of it is pretty limited. I’m not sure what’s the best way; add my settings to SystemSettingsData or write my own struct.

  • Can I add my settings (for example uint8_t something[16]) to the SystemSettingsData struct, just before padding & the checksum without causing all sorts of problems ?

    struct SystemSettingsData {
    uint8_t midi_in_mask;
    uint8_t midi_out_mode;
    uint8_t show_help;
    uint8_t snap;
    uint8_t autobackup;
    uint8_t voicecard_leds;
    uint8_t swap_leds_colors;
    uint8_t padding[8];
    uint8_t checksum;
    };

Why do you use [8]bytes of padding here, does it have to do with memory alignment ? Without the padding it was already 8 bytes right, a multiple of the word size (2 bytes ?) This makes the struct 16 bytes, is this a more efficient way the ATmega664p’s EEPROM has to be aligned ? Or am I just wide of the mark here :wink:

  • If I write my own struct, I’m not sure at which memory address to store it.

From what I can understand, you store MultiData at address 0, the firmware update flag at the last available address (E2END) and the SystemSettingsData at E2END - size of the SystemSettingsData struct.
What’s the reasoning behind this ? Why not let the compiler handle memory allocation (EEMEM) ?

Somethin else I was wondering about when reading up on using EEPROM’s … isn’t it better to use update instead of write ? Ok, it does have 100.000 write cycles :slight_smile: but still.

thanx

The padding is there to reserve space for future improvements. If you want to add setting(s) to the struct, add it (them) after “swap_led_colors” and remove as many bytes as necessary from the padding array.

> What’s the reasoning behind this ?

No particular reason for writing from the E2END. Just a habit I got from writing on systems in which the code and the settings are in the same address space.

> Why not let the compiler handle memory allocation (EEMEM) ?

It doesn’t help much in making sure that the addition/removal of a variable will make a new version of the firmware work with the data written in eeprom by a previous version.

> isn’t it better to use update instead of write

This won’t extend the duration since the limiting factor is the number of times the checksum byte is written - and it’ll change at every write.

thanks Olivier

> The padding is there to reserve space for future improvements. If you want to add setting(s) to the struct, add it (them) after “swap_led_colors” and remove as many bytes as necessary from the padding array.

so I can only add 8 bytes of data myself here ?

Then I need to write my own struct and store it. But where ? E2END - size(SystemSettingsData) - size (mystruct) ?

Or after the MultiData struct, If I knew how many bytes it takes up, which I don’t

> so I can only add 8 bytes of data myself here ?

Yes.

> But where ? E2END – size(SystemSettingsData) – size (mystruct) ?

Yes.

> Or after the MultiData struct, If I knew how many bytes it takes up, which I don’t

Ah, right. Yes, there’s the default multi stored in eeprom too. Now that’s why settings were written from the end of the memory…

I think the multi data + 6x patch + part data amounts to 1664 bytes.

very helpful Olivier, thank you !

now I can get back and finish that pong game I was working on for my Ambika hahahah …

cheers :wink: