I'm about to use the EEPROM library with ESP8266 NODE MCU. I keep reading that "Limited (10K?) write cycles." and "thus will wear out the flash memory very quickly". What does this mean? Will it actually damage the chip or does it just mean the contents need to be refreshed?
It will render the EEPROM inoperative.
With the UNO after the limit is reached, no guarantee that writes to the EEPROM will work.
Assume it is the same with the ESP8266.
The EEPROM (or flash memory in the case of the ESP8266 since it emulates EEPROM in flash) has a physical limit on how many times it can be written. The manufacturer guarantees at least 10K write cycles, but the actually number of cycles for a given chip will likely exceed this and varies from chip to chip. Read cycles are not limited.
I think the ESP8266 has no internal flash, it depends on an external flash IC. So the flash performance depends on the external flash IC specs.
Thanks everyone. I can live with 10K writes. Writing less than once a day I'll buy a new ESP8266 after 27 years. Thanks for clarifying this for me.
How much data do you have to store? There are algorithms to distribute the writes over an EEPROM map so that individual pages aren't written as often. I guess though, with flash emulation that wouldn't be effective.
I used to teach microcontrollers and when we covered EEPROMs I would always stress to make sure the EEPROM wasn't written unnecessarily and that it could be destroyed in under a second by repeatedly writing a location in a program loop.Even so, every couple of years there would be a student who inadvertently (I hope!) did just that.
Professionally I've used the EEPROM in many products where it provides non-volatile storage of product settings. In these applications the contents of the EEPROM was copied into RAM at power-up and would only be written back if the configuration was changed, and then only after a few seconds. There was no way it would ever reach the writing limit! The products ran 24/7 and had 5 year guarantees against failure. None that I knew of ever failed for this reason.
Only a few bytes - settings info for home lighting etc. It will only change when first setting up and then if and when things change, so I wont go over the 10k writes for quite a few years.
Yeah, that's what it's designed for.
There's also always the option of a secondary external EEPROM chip. 24-series I2C EEPROM IC's (part numbers vary by manufacturer but behavior is identical except in ways that rarely matter, or matter only at the hardware level (like operating voltage range, or number of rewrite cycles claimed) and 25-series SPI ones. 8-pin packages (SOIC or DIP).
There are also a bunch of "FRAM" versions of those, which act nearly the same.... except with effectively no write endurance limit (trillions of writes to any given cell), instantaneous writes, no concept of page size and an eye-watering price. But you can write them with reckless abandon.
I think the reason it's listed as (10k?) is that it's using the flash to emulate EEPROM, but the two don't behave exactlty the same; (eeprom is typically with byte granularity; flash is not, so depending on the access patterns you can manage to make flash endurance much lower than a naive expectation from the chip's specs. The W25Q32 is a typical flash chip used for things like the ESP8266, and it specs 100k erase cycles (10x more than the library says) - but can be erased in only 4k blocks, so each 4k block can be erased 100k times, but if you're rewriting new values to already written addresses within that block, if the eeprom emulation library doesn't do something smarter than the minimum about it about it) you could get there from writing just 104k bytes to the same 4k block.... instead of 400,004 kbytes) I don't know if it does or not, and if so how much smarter. But in any event, it looks like you're in safe territory to me based on description of your planned usage and it looks like for the problem at hand, you're in clearly safe territory. I reckon the 10k number was trying to give a real world estimate of endurance that was achievable under typical use cases.