Apehaenger
commented
8 months ago Might be somehow over-engineered, but recognized that the wear level of the flash is caused by the flash-sector-erase and not the flash-page-write (did not know that before). Did some tests and decided to "must try" cause interested in...
So the last commit increases the wear level protection by a factor of about 10 (for the used sample Record.config data) by writing multiple times (10) into the same page, before winding to the next (of 16) page(s)... before doing the wear level expensive flash-sector-erase
Due to this:
- I reduced the wear level write time protection (for production) from 5 to 1 minute
- and for devel/debug from 10 to 1 seconds
In addition I changed the function names to be more reasonable.
In preparation for what we discussed in #80, I wrote some code how I would save a config structure in flash. I preferred to implement it as described by this great blog article instead of the common known Arduino EEPROM library, for an improved wear leveling protection.
Attention: This draft contains some sample/test code which increase config.volume every second (in main.cpp) and for quicker test/debug, wear level protection is shortened to 10 seconds (instead of more protective 1-5 minutes) (in nv_config.h line 29) for changed config members. So, don't leave it running endless even if expected flash EOL time with this 10 second protection will be after approx. 888 hours (20'000 expected flash erase cycles 16 wear level protection 10 seconds write cycle)