6

I want to store a few (8 as of now) IR codes into my Board's EEPROM. It would be great if someone could suggest a few tips to maximize the lifetime.

The IR codes in my sketch are saved in array of unsigned longs.

I know that the count of times that I will be writing to EEPROM will << 100,000 times, but still would like to optimize my sketch. + would help in future projects

  • 3
    Just out of interest, I tried to "wear out" my EEPROM a while back. It took something like 1.5 million writes before it started to fail. – Nick Gammon Feb 3 '17 at 0:50
  • @NickGammon, what were the failures like? Random data? – James Waldby - jwpat7 Feb 3 '17 at 7:04
  • One bit failures, from memory. – Nick Gammon Feb 3 '17 at 8:30
  • It's possible that if you exceed the specifications the memory might become less reliable. I didn't test that. Conceivably you might find that, after a month, a bit would change. My own findings were that you could exceed the recommended ratings by a substantial amount, and still read back the byte you wrote, a moment later. – Nick Gammon Feb 3 '17 at 8:32
4

I can think of a few:

  1. don't power it on unless you have to;
  2. don't write to it unless you have to;
  3. write as little data to you as you can - compress the data; only write to it during brown out or power down, ...;
  4. level the writes to as many cells as possible - increment the write address with subsequent writes;
  5. use a big eeprom;
  6. use fram;
  7. use sram + battery back-up;

...

3 - 7 are really examples of implementating #2.

7

The other answer mentioned some general ideas; here are a couple of more-specific notes.

• You can direct your writes of single bytes through a routine that reads the EEPROM cell before writing to it, and if its value isn't changing, doesn't write.

• For load-leveling, you can divide the EEPROM address space into k buckets, where k =⌊E/(n+1)⌋, with n = data array size and E = EEPROM size. Initialize a directory, an array of m bytes all set to k, with m = E-n·k. When your device starts up, it reads through the directory until it finds current entry, a byte not equal to k. [If all directory entries equal k, initialize the first to 0, and go on from there.] If the current directory entry contains j, then bucket j contains current data. When you need to write new data, you store j+1 into the current directory entry; if that makes it equal to k, initialize the next directory entry to 0, and go on from there. Note that directory bytes get about the same amount of wear as bucket bytes because 2·k > m ≥ k.

  • Thanks, I will try and implement load-leveling to my sketch also. Great explanation. I do check if the values are same before writing, so that part is taken care of. – karx Feb 3 '17 at 18:46
2

If your data occupies only a small fraction of your EEPROM, you could use one of the wear leveling algorithms. The essence of these algorithms is to write to a different location each time, so writes are spread across several locations while each location stays below the 100,000 writes limit.

There are several such algorithms discussed here, which you could implement yourself. Alternatively, you could just use a library like this one.

  • 1
    These are great links Dmitry! Thanks. Anyways, now I am using ~the entire EEPROM for data. Write operations are rare in my code and only happen during the start of the lifecycle (configuration period of my device). The lifecycle mostly consists of only read operations. As the size of my config-files is increasing I am now looking for memory-optimization techniques to fit all that in the EEPROM and no go for any additional storage. – karx May 10 '17 at 22:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.