This could be mitigated by introducing a config version parameter that would tell if there was a firmware change. So there needs to be a lookup table that tells which variables have been added by which version and then some dispatcher code can figure out for the current version which variables to initialize after the first boot.
A simplified version of this exists already. It isn't as elaborate as what you describe here. I am always wary of the need for code simplicity; though currently only about 1/3 of the QMX microcontroller's codespace is utilized, it is still important not to fall into the trap of the modern day software developer's greatest fallacy: assumption of infinite CPU speed, infinite space, infinite memory, and zero latency (network, processing etc)! Sorry this is a pet rant of mine, after 22 years in software development in the finance industry... we best close the rant before I get carried away. To make it simplest: though we currently have a lot of spare space in QMX, I'm still always trying to think of the most compact way to code things, because I have so many future plans for it!?
The problem on the 024 release was that I re-used an EEPROM variable, the CW filter selection in 023, which in 023 had possible 13 values, as CW filter passband in 024. But in 024 it has only 9 possible values. If someone happened to have selected a firmware 023 filter, then the power-up initialization would try and find a non-existent filter and wander off into other areas of memory. Hang up, in other words. It's easy to fix, I just didn't think of this possibility! Not thinking of a possibility could happen on any way of handling things.?
