Is there a common way to handle changes in the mapping between eeprom addresses and variables between firmware versions? It's not about the eeprom memory to survive the update, but to be(come) compatible with future sketches with a possibly different set of variables.
To make it clearer consider the following fictional scenario:
A coffee machine has been programmed to measure water_temperature
and the firmware is supposed to stop heating within a temperature_hysteresis
below set_temperature
. set_temperature
is a persistent parameter that has been individually optimized be the user and must therefore survive any firmware update. As a configuration parameter also temperature_hysteresis
is stored in the eeprom.
Now the manufacturer decides to update his machine with a PID-controller, making the parameter temperature_hysteresis
obsolete while he introduces some new parameters for the controller's gains (pid_gains
). How can he manage that the firmware keeps values that haven't been touched by the update (like set_temperature
) while the additional parameter pid_gains
is added.
I assume that obsolete parameters should be removed as there could be more updates with new parameters in the future. That's why simply incrementing the eeprom address and ignoring deprecated addresses probably won't work.
On the other hand, when re-using old addresses I wonder how a fragmentation of the eeprom can be avoided. I came up with the idea of putting all configuration data into a json in the eeprom and to handle the problem a layer above by parsing the json for configuration data. But anyhow, that feels so wrong and might be too complicate.
Does anyone have experience with this kind of problem and knows how this routine is commonly implemented?