We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I apologize for the maybe stupid question. For the first time planning to use EEPROM for a larger number of calibration constants, saving operating modes (such as the number of starts) and logging errors. Seeking examples or libraries for this purpose. Pperhaps a graphical utility for assigning addresses and generating an address in EEPROM
Interesting thread. Using the structure is interesting, unfortunately, does not solve the division of EEPROM on pages. for example eeprom witd 16byte page
struct eeprom { uint32_t num_A; //0-4 uint32_t num_B; //5-8 uint32_t num_C; //9-12 uint16_t num_D; //13-14 uint8_t num_E; //15 uint16_t num_F; //16-17 first byte will on page1 and seceond byte will on page2 }
If write 16bit num_F will rewrite page1 and page2
Unless that "Non-Specific (Generic)" CPU you claim to be using is really very old-fashioned, that's actually quite likely an incorrect prediction.
When having 16-bit constants and page boundaries, then normal C optimization would add a pad byte so a struct would place the 16-bit constants at an even address - so no page boundary break.
But this can't help when the OP has 96-bit constants. The way to use structs to keep track of the offsets then is to have multiple structs - one for each page. And then have an assert that complains if the struct is larger than one page. So new constants are added to a struct, and the assert tells if it works, or if the new constants instead have to be pasted into one of the other page structs.
And the common rule of always placing the largest data types first takes care of giving them best align and avoiding the compiler having to insert lots of hidden padding.
then normal C optimization would add a pad byte
Optimizition may not have much to do with it. It may just as well be a necessity.
Well, it is a form of optimization to not have to treat the data as packed and split an access into multiple loads or stores :)