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.
Enumerated addresses are normally handled with enum { ... }.
Or you could create a struct:
enum { NUM_UNITS = 4, NUM_ERRORS = 16, }; struct error { uint32_t time; // unix epoch of error - 0xffffffff if empty entry. uint32_t uptime; // uptime in seconds when error detected uint8_t errcode; uint8_t subcode; uint16_t misc; }; // Use this struct to retrieve the offset of individual fields in the EEPROM // Optionally make the structure packed, in case there is no need to also keep // a RAM copy of the data. struct eeprom { // <= optionally make structure packed uint16_t magic; // Magic value that EEPROM is initialized uint16_t version; // Version information of data. uint32_t num_reboots; // # of times program has booted uint32_t num_watchdog; // # of times program has had wd reset. uint32_t num_starts[NUM_UNITS]; // Total # of motor starts uint64_t num_seconds[NUM_UNITS]; // Total # of seconds of running time uint32_t num_startup_seconds[NUM_UNITS]; // Total # of seconds to nominal RPM uint32_t last_startup_seconds[NUM_UNITS]; // # of seconds to nominal RPM for last start ... // Last error codes in a circular buffer. struct error err_log[NUM_ERRORS]; }; bool read_eeprom_u8(unsigned offset,uint8 *val); bool read_eeprom_u16(unsigned offset,uint16 *val); bool read_eeprom_u32(unsigned offset,uint32 *val); bool read_eeprom_u64(unsigned offset,uint64 *val); bool read_eeprom_raw(unsigned offset,void *p,unsigned len); bool read_log_entry(unsigned seq,struct error *err); bool write_eeprom_u8(unsigned offset,uint8 val); bool write_eeprom_u16(unsigned offset,uint16 val); bool write_eeprom_u32(unsigned offset,uint32 val); bool write_eeprom_u64(unsigned offset,uint64 val); bool write_eeprom_raw(unsigned offset,const void *p,unsigned len); bool write_log_entry(const struct error *err);
Next thing is if you have individual entries you will write so often, that you might need to rotate the writes over multiple cells for wear leveling - but that is often not needed since traditional EEPROM normally supports many times more writes than flash memory.
Just remember that if you release a new firmware that changes the layout of the EEPROM data, you either need to erase all EEPROM data, or write code that either adapts to new/old layout or reads out the old information and then writes it back in the newer format. So it's good to have some version information in the EEPROM so you know the format of the current data.
>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 :)