Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Thread

Distributing wear on EEPROM writes?

Distributing wear on EEPROM writes?

2005-06-09 by David Kelly

The classic example of what I'm thinking is an electronic odometer on a
car. One must write periodically to nonvolatile memory such as EEPROM
but limited to something like 10,000 erase/write cycles to represent
1,000,000.0 miles.

Have heard mention of it somewhere before but can't find/derive a
solution this morning where rather than represent every 0.1 to 1E6 in 24
bits that writes be distributed over something like 128 bits. More like
counting days with a tally on a prison wall, only toggle one bit per
unit. Set all the bits from one end to another than start back at the
beginning and clear.

The problem with writing my raw count to EEPROM is that to increment
from 0 to 1 is only one bit toggle, but 1 to 2 is one on one off, 3 is
only one on, 4 is one on two off. Wasteful of EEPROM wear.

Another thought is to use Hamming codes and write multiple copies. The
AVR has way more EEPROM than I really need as I have only about 20 bytes
total of parameters, plus need for a summing register.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

RE: [AVR-Chat] Distributing wear on EEPROM writes?

2005-06-09 by Tom Becker

> ... Distributing wear on EEPROM writes?

ATEML appnote AVR101:
http://www.atmel.com/dyn/resources/prod_documents/doc2526.pdf


Tom



Tom Becker
--... ...--
GTBecker@RighTime.com www.RighTime.com
The RighTime Clock Company, Inc., Cape Coral, Florida USA
+1239 540 5700

Re: [AVR-Chat] Distributing wear on EEPROM writes?

2005-06-09 by Dave VanHorn

>
>Another thought is to use Hamming codes and write multiple copies. The
>AVR has way more EEPROM than I really need as I have only about 20 bytes
>total of parameters, plus need for a summing register.

An approach I've used, is to start with it erased, and do readback 
verify on the data.
When area X fails, then you move to area Y.
To read the data, or to start again after a power failure, you scan 
till you find FFFF...FF (erased data) then you back up a notch, and 
that's the active area.

So, if you had 8 bytes to write, you'd maybe start at location $0008 
(avoiding zero)
Then when $0008-$000F wear out, you move to $0010-$0007 and so on.
It's simple and straightforward.

Re: [AVR-Chat] Distributing wear on EEPROM writes?

2005-06-09 by Neil

I'm doing this (on a PIC) currently -- I virtually sectioned the available 
EEPROM into sets of 4 bytes each, with each set holding 3 bytes of data and a 
checksum/validity indicator.  Each save writes to the next set in sequence, 
looping around to the first set when necessary.  On power-up, I read back all 
sets and use the highest valid dataset as the current one, continue counting 
form there, and continue saving from the set after that.  The checksum is 
there in case only some of the bytes in a set get properly written and some 
fail.

Cheers,
-Neil.



On Thursday 09 June 2005 10:50 am, David Kelly scribbled:
Show quoted textHide quoted text
> The classic example of what I'm thinking is an electronic odometer on a
> car. One must write periodically to nonvolatile memory such as EEPROM
> but limited to something like 10,000 erase/write cycles to represent
> 1,000,000.0 miles.
>
> Have heard mention of it somewhere before but can't find/derive a
> solution this morning where rather than represent every 0.1 to 1E6 in 24
> bits that writes be distributed over something like 128 bits. More like
> counting days with a tally on a prison wall, only toggle one bit per
> unit. Set all the bits from one end to another than start back at the
> beginning and clear.
>
> The problem with writing my raw count to EEPROM is that to increment
> from 0 to 1 is only one bit toggle, but 1 to 2 is one on one off, 3 is
> only one on, 4 is one on two off. Wasteful of EEPROM wear.
>
> Another thought is to use Hamming codes and write multiple copies. The
> AVR has way more EEPROM than I really need as I have only about 20 bytes
> total of parameters, plus need for a summing register.

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.