Best way to store 64 bits of user parameters

piere_delecto

New member
I am working on a project and would like to allow the user to store a very small amount of data (like 64 bits) that they can continuously change as needed. I think I'd like to use eeprom, if possible, to avoid adding an additional memory module to the project. Would LittleFS be helpful for this application? I understand that I need to be careful about re-writing to the same area of memory many times.

Thank you
 
If you are worried about writing to EEPROM too often you can use the update function to ensure that you are not stressing the memory if the actual value hasn't changed.

I don't have any experience with LittleFS but it seems like overkill if you are only dealing with a small amount of data in my opinion.
 
Just use EEPROM get and put. I believe the EEPROM library does auto wear levelling.
EEPROM on Teensy does wear leveling for sure.
Also, only updates when value changes: if (data == olddata) return;
** Note that is on the BYTE level: so not all four bytes might even change with each update


LittleFS overkill for sure with the Fail Safe overhead has multiple link/index elements updated on writes. It doesn't work at the byte level, but larger blocks will get updated - it does wear level - but will leave dirty blocks with just small updates.

The 1062 does have 4 32 bit DWORDs of NVRAM that survive restart but not power loss. Much faster and no wear - as long as every update isn't critical - that could be saved to EEPROM on some required time frame.
 
I have several applications that store user settings. I use the EEPROM all the time. I'm storing some 300 bytes and have never lost a bit.

Not sure what you are trying to write but EEPROM.put and EEPROM.get let's you write data, and these functions write the necessary bytes based on what's being written

#include <EEPROM.h>

float thing1 = 15.2;
EEPROM.put(10, thing1); // 4 bytes written

EEPROM.get(10, thing1);
// thing1 will be 15.2


byte thing2 = 44;
EEPROM.put(15, thing2); // 1 byte written

EEPROM.get(15, thing2);
// thing2 will be 44

If you need to save at the bit level, you will need to still write at the byte level but just parse as needed

caution you have limited reads/writes before that memory gets unusable. Google says 100,000 to 1,000,000 times.

Hope this helps
 
Thank you all for your assistance and knowledge. Kris, the example code will be a big help. As nopayne mentioned, I suppose i should use .update() rather than .put() to avoid redundant writes.

This is for a drum machine. I'm hoping to allow the user to save drum patterns and, eventually, parameter settings.
 
To simplify and put into context - EEPROM.put on the T4 will do the same as .update for you, so use EEPROM.put. If the user constantly saves their settings every hour, 24 hours a day, 7 days a week, it will take them almost 12 years to do 100,000 saves and likely 50-100 years of doing this before wearing from repeated writes may be an issue, so for this use case, don't worry about wearing, its a non-issue for this use case. It's hard to get to 100,000 events with purely human interaction, but easy when machine driven. Plus, drummers don't last that long :)
 
Last edited:
Plus, drummers don't last that long :)
I don't recall seeing the entire mockumentary, but I recall Drummers for the Spinal Tap band did not have a long life span:

Spinal Tap's fictional history documents a succession of drummers, all of whom are said to have died in strange circumstances: one in a "bizarre gardening accident"; another who "choked on vomit", but possibly not his own vomit; and two from "spontaneous human combustion" onstage.

And at the moment, of the 4 Beatles, only Ringo Starr has 2025 performance dates available (though Paul McCartney will be doing a tour in 2025, no dates are yet scheduled).
 
I can confirm the EEPROM emulation within the core library does indeed do wear leveling. For small data like 64 bits, you can expect the wear leveling to multiply the underlying 100K endurance by a factor of 256 to 512.

Extremely unlikely to run into endurance issues if the writes are paced by human activity changing settings.

Reading doesn't stress the flash. Endurance is only about about writing.
 
Back
Top