arduino-esp32
arduino-esp32 copied to clipboard
espressif
A "bool isDirty();" would be useful in "libraries\EEPROM\EEPROM.h" & "libraries\EEPROM\EEPROM.cpp"
Related area
"libraries\EEPROM\EEPROM.h" & "libraries\EEPROM\EEPROM.cpp"
Hardware specification
ESP32 and also ESP8266
Is your feature request related to a problem?
To reduce eeprom usage in deep-sleeping Sensors which store data-readings in EEPROM, I initally store readings in the rtc-memory (which is retained over deep-sleep), and then only transfer them into EEPROM every hour or so, which significantly reduces the number of "EEPROM.commit()" commands required.
However, it is very useful to know if the EEPROM is dirty (for some other reason) before going to sleep, as if it is then I can transfer any readings from rtc-memory into the EEPROM before doing an "EEPROM.commit()" and going to sleep.
Describe the solution you'd like
(1) add "bool isDirty();" to "libraries\EEPROM\EEPROM.h"
(2) add "bool EEPROMClass::isDirty() {return _dirty;}" to "libraries\EEPROM\EEPROM.cpp"
(I have manually edited these files on my system.)
Describe alternatives you've considered
No response
Additional context
No response
I have checked existing list of Feature requests and the Contribution Guide
- [X] I confirm I have checked existing list of Feature requests and Contribution Guide.
The source library does not include getDirty(). EEPROM is provided for Arduino portability. If you are writing code only for esp32, use the Preferences library, or directly using the NVS library, which allows you to manually commit.
@lbernstone - Many thanks for your comments.
You say "The source library does not include getDirty(). EEPROM is provided for Arduino portability."
If I understand correctly, you are saying that it’s not appropriate to add a “getDirty()” function to the https://github.com/espressif/arduino-esp32/blob/master/libraries/EEPROM/src/EEPROM.cpp and https://github.com/esp8266/Arduino/blob/master/libraries/EEPROM/EEPROM.cpp libraries because the original Arduino-AVR-EEPROM library does not have or need this function.
I note that the above ESP32 and ESP8266 EEPROM libraries already have the ESP-specific “EEPROM.commit()” function (which only actually writes the flash if anything has changed), that the AVR library neither has or requires.
Also, the EEPROM in most AVR chips is “proper EEPROM” with lifespans of approx 100,000 writes, where as the ESP EEPROM is emulated in standard FLASH memory, so only has lifespans of approx 10,000 writes.
Additionally the ESP chips do not retain RAM memory over Deep-Sleep, so sleeping sensors need to store readings in EEPROM before every sleep, which is something most AVR chips don’t need to do as they retain their RAM during sleep. Thus Deep-Sleeping ESP sensors need to be much more careful with EEPROM usage.
As and example, consider an ESP sensor which takes a reading every 60seconds and then goes to Deep-Sleep for 60seconds, and saves a say 2 byte reading in EEPROM before every sleep. This would makes 1440 EEPROM writes (EEPROM.commit()) a day, using in total of 2880 bytes of EEPROM (max size 4096), which is then transmitted to a server once a day.
As, the ESP FLASH-EEPROM is page addressed in typically 64byte pages (ie. 45 pages in the 2880 bytes). This means the 1440 EEPROM writes actually changes each page only 32 times in a day. But 10,000/32 gives an EEPROM lifetime of only 312 days (ie less than 1 year).
So careful management of ESP FLASH-EEPROM is essential.
If one instead stores say 16 sensor readings (16 minutes) in rtc-memory, before transferring them into EEPROM in one go (32bytes), we reduce EEPROM usage a 32 byte write every 16 minutes, (so 2 writes per 64byte page per day). So 10,000 writes at 2 writes per day gives an EEPROM lifetime of 13 years
However my sensors also intermittently record other status info in the EEPROM, so being able to identify this and write the rtc-memory data at the same time saves EEPROM writes and also time-matches the sensor-data with the status-messages.
This is why the above detailed “isDirty()” function is essential to my ESP sensors, and I suspect would also be very useful for others.