ESP32 - using EEPROM.write vs. using .put or .write (etc)

[IraSch]

I'm working with an Adafruit Huzzah Feather ESP32:

I need to store some information between power cycles. Only about 32 bytes made up of integer variables.

Searches have led me to both EEPROM.write and to Preferences.putbytes (or .write). I believe that .write only works with individual bytes (0-255) of memory and I have to manage it, which is OK. I believe that .putbytes/.write works with a block of memory that I can map to a structure, which is also OK.

Seems like EEPROM is simpler since .putbytes/.write involved memory copies to/from a buffer.

Is there a reason to use one over the other?

Also, I've seen .putbytes in some examples, and .write in others - is there a difference.

And while I'm at it, I understand that re-writing variables to flash memory can be done a limited amount of times. But are we talking dozens, hundreds or thousands of times?

Thanks in advance for you help.

[ESP_Sprite]

I think the Preferences library is preferred at this moment. Both it as well as the EEPROM library use nvs underneath which does wear levelling; if you only write 32 bytes you should be able to write them a million times or so without issue.

[lbernstone]

EEPROM is provided for compatibility/portability with the Arduino API. It is implemented as a putBytes blob in nvs, so will use more space and cycles in general than directly using Preferences (which gives you more flexibility in the allocation). If you look at the Prefs2Struct example (https://github.com/espressif/arduino-es ... Struct.ino), you can see a simple way to take a set of configuration options and directly push or pull them into a NVS(non-volatile storage) name space.

[IraSch]

I pulled down the example from Github but when compiled it gives an error 'class Preferences' has no member named 'getBytesLength'

Not a big deal, I can still use the example to see how Preferences work, but not sure why the error.

I downloaded the latest version and that does include the GetBytesLength function, but I would have thought there'd be a change log entry

Thanks for the info.