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
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?