Save stats to NVRAM.

[romanmashta]

Feature:

• Save stats to NVRAM.

Improvements:

• Remove first time switch screen lag by drawing screen before fetching global data.
• Remove 1 second switch screen lag.

[roblatour]

Just saw this pull request go up.

If you're planning to save the stats to non-volatile memory, how often are you doing this? I looked at the proposed code change and it appears that it is planned for every 5 minutes.

If this is the case, you could hit the maximum of 10,000 write cycles for each memory location in the ESP32 Flash Memory in just over a month, after which time I suspect things will not be good if I am reading the following correctly:

ref: https://deepbluembedded.com/esp32-flash-memory-spi-flash-arduino/#:~:text=ESP32%20Flash%20Memory%20Write%20Cycles&text=A%20typical%20EEPROM%20can%20have,in%20the%20ESP32%20Flash%20Memory.

[romanmashta]

Thanks for the info. That's valid point. Did not had idea that it is so limited. I think I will make it progressive like, 5 minutes, then 15 e t c, right up to 12 hours and will keep it. So for long single uptime session it will use 12 hour intervals most of the time. With that it should last for years.

[roblatour]

The 10,000 max limit applies if you keep writing to the same spot every time. You might want to consider some scheme where the area that you write to rotates; but if you have a pointer to that you need to be able to rotate the location of the pointer too. I don't know if this is fully implemented here but that's the idea. Also, you should only write a byte value when the value of a byte changes. Take a look at this project in the .ino file in the subroutine writeEEPROMString(int address, String data) to see what I mean.

In any case, saving to non volatile memory needs to be done carefully esp. if your going to do it a lot, or you end up toasting the board over time and having a lot of unpleased people.

[romanmashta]

I use Non-Volatile Storage Library API for saving state. It has an internal wear leveling mechanism according to documentation. https://espressif-docs.readthedocs-hosted.com/projects/esp-faq/en/latest/software-framework/storage/nvs.html#does-nvs-have-wear-levelling-function However if writing stats two times per day still considered a lot, probably that feature is not so cool as it sounds.

[romanmashta]

I'm closing it as nvs stat storage will require further investigation and coding to be sure that stat saving can work for long enoguh time.

[BitMaker-hub]

Hi Guys thank @roblatour for pointing this and totaly agree. In past there was an aproximation of this and was thought because there were many reboots. I opposed it because of this. We finally got the issue and was not needed.

Today code is really stable and yes, this variables would liket to be saved but coud not be necessary.

On that point I'll say that saving Best share gotten by a NerdMiner could be nice. Only when the previous value is saved. We could discuss this

[BitMaker-hub]

@romanmashta, can you PR again just with improvements?

[romanmashta]

Yes, I will investigate the best strategy and impact on storage, so we can have clear expectation if it will work for month or for years. And will make this as feature toggle through definition. So it will be optional.