EEPROM write limitations and how to maximize their usage
KaosKidd
Posts: 296
In a number of threads, a number of times, the issue of getting around the write limitations of EEPROM have come up. From part replacement through software cycling an number of solutions have come up. I thought I'd start a thread dedicated JUST to this issue because it does come up frequently.
When designing your project, you should start thinking early in the process about what data needs to be stored and how often it will need to be updated. This could be as simple as a few pointers / calibration numbers, or as complex as a complete log. If you know you are going to be relying on nonvolatile storage, think before you design.
The facts of the problem are quite simple: EEPROMS are limited to the number of writes that one can preform to the same location. Depending on how much data must be retained and how often the EEPROM will be written to will govern what method you would imply to avoid the issue.
Hardware: RAMTRON has a solution, the FM24V05 , which is compatible with the AT24C512 AT24C512 and for all intentions would be considered the preferred solution to the problem. This device really covers all of the bases when it comes to long term, repeated writes (and reads) to nonvolatile storage.
Programming: However, sometimes cost does become an issue, or the write cycle is not very intense. In this case, one can resort to programming to "load level" the EEPROM to extend the life of it's writing. In theory, there are a number of answers that work. Remember, in programming, there is no right or wrong way, just faster or slower (read more efficient vs less efficient) ways of doing things. In this particular subject, there are two schools of thought: Use a cell until it breaks or, cycle through all the cells. In either method the program is going to have to verify the write worked; this is the only way to provide the detection of either the End Of Life for the whole EEPROM (as it would be for Cell Cycling) or the End Of Life for a series of cells (as would be the case for single cell max usages). In either case, its a simple call to compare what was written vs what's read.
When programming, some simple things can be done to extend either method further:
#1: When you jump to your save routine, only save the data if it's different then what's in memory. This works for both data loggers AND VAR (pointers and the such) storage models. This is called DELTA saving, and it could possibly extend the life of your EEPROM by 50%, again this depends on what's being saved.
#2: When saving your data, PACK it into as tight a memory model as your application requirements permit. (IE Speed and timing are the governing aspects here). This will reduce the number of memory locations needed / affected with the writes. In theory every byte you pack is a memory location that can be added to the pool of available cells.
My spin is not even worth while to type (I've been away for nearly 5 years but I'm getting back into it), and assembler even worse, so I'm not even going to try to write workable code, but any of the super P-Coders out there could provide a basic idea on how to get this job done.
Ok, that just my humble opinion on the subject; does anyone else have suggestions or things I forgot about?
KK
When designing your project, you should start thinking early in the process about what data needs to be stored and how often it will need to be updated. This could be as simple as a few pointers / calibration numbers, or as complex as a complete log. If you know you are going to be relying on nonvolatile storage, think before you design.
The facts of the problem are quite simple: EEPROMS are limited to the number of writes that one can preform to the same location. Depending on how much data must be retained and how often the EEPROM will be written to will govern what method you would imply to avoid the issue.
Hardware: RAMTRON has a solution, the FM24V05 , which is compatible with the AT24C512 AT24C512 and for all intentions would be considered the preferred solution to the problem. This device really covers all of the bases when it comes to long term, repeated writes (and reads) to nonvolatile storage.
Programming: However, sometimes cost does become an issue, or the write cycle is not very intense. In this case, one can resort to programming to "load level" the EEPROM to extend the life of it's writing. In theory, there are a number of answers that work. Remember, in programming, there is no right or wrong way, just faster or slower (read more efficient vs less efficient) ways of doing things. In this particular subject, there are two schools of thought: Use a cell until it breaks or, cycle through all the cells. In either method the program is going to have to verify the write worked; this is the only way to provide the detection of either the End Of Life for the whole EEPROM (as it would be for Cell Cycling) or the End Of Life for a series of cells (as would be the case for single cell max usages). In either case, its a simple call to compare what was written vs what's read.
When programming, some simple things can be done to extend either method further:
#1: When you jump to your save routine, only save the data if it's different then what's in memory. This works for both data loggers AND VAR (pointers and the such) storage models. This is called DELTA saving, and it could possibly extend the life of your EEPROM by 50%, again this depends on what's being saved.
#2: When saving your data, PACK it into as tight a memory model as your application requirements permit. (IE Speed and timing are the governing aspects here). This will reduce the number of memory locations needed / affected with the writes. In theory every byte you pack is a memory location that can be added to the pool of available cells.
My spin is not even worth while to type (I've been away for nearly 5 years but I'm getting back into it), and assembler even worse, so I'm not even going to try to write workable code, but any of the super P-Coders out there could provide a basic idea on how to get this job done.
Ok, that just my humble opinion on the subject; does anyone else have suggestions or things I forgot about?
KK
Comments
It seems like a count should be maintained as well. The EEPROM could be divided into blocks depending on the size of the application's data, and each block would be tagged with a count of zero initially. The count would be incremented every time a block is written. When a block count reaches the deivice's specification the program moves on to the next block.
Devise Temp would most assuredly have an effect on it's reliability. I personally believe in a rolling method... IE Read the pointer, on the next update, increment the pointer, when you hit the top, roll over back to the beginning. This with a count of the number times through the eeprom (and notification of some sort) to predict before the End Of Life happens. I would make the blocks an int of the data size / size of eeprom using, thus maximizing the number of blocks that can be used.
KK
Great!
This is the sort of thing beginners (and sometime intermediate and advanced) programmers need access to.
KK