I tried using EEPROM.update() today as per the documentation here:

The compiler gave the following errpr:

exit status 1
'class EEPROMClass' has no member named 'update'

What gives? Is this now deprecated? Does write and put now behave as update?

Which Arduino board are you using ?

This is on an ESP8266. I believe that EEPROM is somehow emulated on this board so maybe this function has no real value, but the information is still stored in non-volatile memory somewhere so it seems to make sense that the "update" function would map across somehow even if just for consistency/compatibility?

The EEPROM functions for the ESP8266 differ from those available on Arduino boards, as you have discovered

it seems to make sense that the "update" function would map across somehow even if just for consistency/compatibility?

I entirely agree, but the ESP8266 boards are not Arduinos and hence not the responsibility of the Arduino project, so you would need to take up the matter with the creators of the ESP8266 sub-system

On an ESP the doc states

This is a bit different from standard EEPROM class. You need to call EEPROM.begin(size) before you start reading or writing, size being the number of bytes you want to use. Size can be anywhere between 4 and 4096 bytes.

EEPROM.write does not write to flash immediately, instead you must call EEPROM.commit() whenever you wish to save changes to flash. EEPROM.end() will also commit, and will release the RAM copy of EEPROM contents.

EEPROM library uses one sector of flash located just after the embedded filesystem.

Three examples included.

Note that the sector needs to be re-flashed every time the changed EEPROM data needs to be saved, thus will wear out the flash memory very quickly even if small amounts of data are written. Consider using one of the EEPROM libraries mentioned down below.

So your interface to EEPROM are the following methods

  void begin(size_t size);
  uint8_t read(int const address);
  void write(int const address, uint8_t const val);
  bool commit();
  void end();

update on an AVR helps save some write cycles by reading first the memory before writing only if it has changed. On an ESP you work in RAM and then it's saved to flash when you call commit().

==> the update() call does not make much sense in that context.

Thank you for the explanation. That makes clear why there has to be a commit() on the ESP.
Would I be better of using spiffs? The reason I stuck with EEPROM.h is to maintain consistency across devices including Uno, Nano, Micro, Mega2560, ESP8266 and ESP32, although only the WiFi devices run a webserver. That might change when I add Ethernet to the Mega2560 though. I am unclear about a number of things with regards to spiffs though:

  • can one use spiffs on Uno? Nano? Micro? I get the impression that its only for ESP devices?
  • can one update files in spiffs storage at runtime?
  • can spiffs be used even while using the HTTP or OTA updater?

Spiffs is being deprecated and at some point will be pulled out so you would ce better off looking at LittleFS or other alternatives

You probably won’t have a magical cross platform solution that uses different underlying technology unless you create yourself an hardware abstraction layer. File system operations could help but would mean using an SD card on small AVR Arduinos

Its news to me that spiffs is being deprecated, so thanks for that bit of info and pointer to LittleFS which I have never heard of. Fortunately the only thing that is being changed is the device config which will not change very often. That was also a reason for sticking with EEPROM, but I take your point that there will probably be no single solution that will work on all platforms. Thank you.

Its news to me that spiffs is being deprecated,

something to read here about Filesystems