Tomas HübnerandGitHub
cd9ea6fb4c
* Update I2C_eeprom.cpp Added page sizes for larger memory sizes (still deriving from the ATxxCxxx datasheets) * Update I2C_eeprom.cpp * Update I2C_eeprom.cpp * Added the cyclic store implementation. * Added an example * Removed redundant #ifdef in include file. Added an incude directive for base "I2c_eeprom.h" file to get the Arduino IDE of the Github workflow to compile the file properly. Added entries to keywords.txt for syntax highlighting the new class and it's members. * Removed debug code that shouldn't have been left in there. * Removed reduntant member and changed the type of the _pageSize to 8-bits. * Changed signature of begin() to match page size data type. * Made the initialization propagate read failures. Added method to get metrics. Fixed bugs in binary search and wrapping of slot index. Tidied up comments. * Added the getMetrics() method to keywords.txt for highlighting * Changed the way getMetrics() works when eeprom is empty. * Titantompa/readme (#7) * Added readme for the cyclic store * Added link from main readme to cyclic store readme.
2.0 KiB
I2C_eeprom_cyclic_store
Utility class for storing data using cyclic writes to eeprom memory
Description
In order to maximize the life expectancy of an eeprom this class implements a method to spread the write operations across as much of the eeprom as possible, rather than writing to the same fixed location.
This is suitable for a situation where a single data structure (buffer), such as settings, configuration or metric data, is written to the eeprom.
It operates by partitioning the eeprom into slots large enough to hold the declared buffer (and header) and then writing each new version of the data to the next slot, overwriting any older version already in there. As it reaches the end of the alotted region of the eeprom it wraps around and starts writing from the start of the memory again. When initializing an instance it scans the eeprom to find the last written version and continues from that.
In order to use an eeprom that already has data (and if the structure of the buffer changes) the eeprom has to be prepared by formatting the indexes.
The interface is pretty straightforward
- begin(eeprom, pageSize, totalPages) initialization
- format() erase data from eeprom
- read(buffer) read buffer from last location prom
- write(buffer) write buffer to next location on eeprom
- getMetrics(slots, writeCounter) get usage metrics
Limitation
The class does not handle changes in buffer size or structure, nor does it detect an eeprom that has data that wasn't written using the class.
Operational
See examples