How does tcMenu handle non valid values already in the EEPROM

[tomelgato]

One Q raised during bug tracking. What happens when there is a value in the Eeprom which is out of range in regards to the linked menu item? Is tcmenu failsafe here?

[davetcc]

I'm not sure what you mean by out of range, couldn't it only be out of range if it were set to a value that were out of range.

For initial setup purposes, the EEPROM values will only ever be loaded if the magic number is stored in the first two positions matches what's expected. Further, if sized-based checking is enabled, it will not attempt to load back any values beyond the previously stored size. You can read about this more in the documentation: https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/menu-eeprom-integrations/

[tomelgato]

I had my eeprom range for tcmenu reserved from 0-199. From 200 on i used it directly for other stuff. Now my Tcmenu stuff did outgrow the size, so i moved my own stuff to 300+ and tcmenu added at sometime above 200 (or me adding new items to tcmenu)
Thats why it did access whatever values.
And yes i know this was not the proper way to do it ;)

I was just wondering during tracing my 4.1 upgrade problems, but in fact it was not related.

[davetcc]

I recommend everyone uses size-based EEPROM unless a legacy reason prevents it. It was explicitly created for this situation. As per the documentation linked above.

[tomelgato]

Yes true. In my case it was some sort of legacy indeed. From the old tcmenu days where i was bugged with crashes of menuload ;) Time to rework the code :)

But ... the size based would not save me. Cause when i copy my private block from 200 to 300 and then change the size in tcmenu it would again get some old values, no?
I know i could avoid it with a clean eeprom migration (move values from 200 to 300 and zero from 200 to 199), it was just a Q out of interest

[davetcc]

Cause when i copy my private block from 200 to 300 and then change the size in tcmenu it would again get some old values, no?

You don't change the size, tcMenu does that on the next save, so on the first load after the move took place it would stop at whatever size was last recorded during save.

[tomelgato]

So if you create a new menu item and it gets eeprom #200 storage where you had written some value directly before ... it will read the existing old data, no?
Anyways, its becoming a academic discussion ;) Was no clean migration by my side.

[davetcc]

So let's write what happens as pseudo code when sized EEPROM support is enabled, it will be useful for others in future too:

1. TcMenu saves an analog item at position 4, it is 2 long, so the maxWritten is now 4.
2. TcMenu now saved a text item at position 6, it is 10 long, so the maxWritten is now 6 + 10 = 16.
3. TcMenu now saved an enum item at position 16, it is 2 long, so the maxWritten is now 16 + 2 = 18.
4. Saving is now complete and the uint16_t magic number is written in position 0 and the uint16_t maxSize in position 2.
5. A new firmware is added with an extra analog item at position 20 of length 2
6. Some time later the board resets and load is called
7. TcMenu now checks the magic number is correct, if not loading does not start
8. Then the maximum saved position is read from position 2, it was 18
9. TcMenu sees the analog item with position 4, length 2, it is loaded back because 4+2 <= maxLength
10. TcMenu sees the text item with position 6, length 10, it is loaded back because 6+ 10 <= maxLength
11. TcMenu sees the enum item with position 16, length 2, it is loaded back because 16+2 <= maxLength
12. TcMenu sees the newly added analog item at position 20, because 20 + 2 > maxLength it is NOT loaded.

[tomelgato]

Perfect, thanks!