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
>Not sure why a graphical tool would be helpful I have over 300 calibration constants (8,16,24,32,96 bit) Everyone must - identify (name) - length - address (position in EEPROM,check position in to page of eeprom) - make documentation - then to establish a code in C (header etc)
not least in order to keep it around even when things change Currently uses Excel and many color cell ,but I think it had to have someone write a program
Note that it's only if each constant must fit on a single page that you need additional help. But should be enough with a simple list
struct { const char *name; eetype_t type; const char *description; unsigned offset; } eeparams[] = { {"sensor_1", EE96, "Hyperlight fluctuation sensor 1 - left frustrum." }, {"sensor_2", EE96, "Hyperlight fluctuation sensor 2 - right frustrum." }, {"door1", EE16, "Front cabin door pressure sensor." }, {"door2", EE16, "Cargo door pressure sensor." }, ... {0}};
And then have a program run through the array and assign the individual sensors. Maybe just split when a page is full. Maybe group different types to different range of pages. And then emit:
#define READ_SENSOR_1(x) eeread96(0,0,x) #define READ_SENSOR_2(x) eeread96(0,12,x) #define READ_SENSOR_3(x) eeread96(0,24,x) #define READ_DOOR1(x) eeread16(1,0,x) #define READ_DOOR2(x) eeread16(1,2,x) ...
and one or more HTML tables. Maybe one on name. One on page. One on type.
Potentially a separate structure that you can include into the program for later runs, that contains sensors you have already locked down, so changes to your sensor list doesn't move already known sensors.
Potentially a struct informing the program about new sensor addresses since previous version - i.e. sensor positions that might lack valid data on first run after a program update.
Anyway - doesn't seem more than a couple of hours. I don't think you can find any graphical tool that can manage better than Excel - and the disadvantage with Excel is how to make sure the source code is synchronized with the spreadsheet. Secondary documentation tends to be stale.
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 :)