Alan B. Pearce wrote:

> Yeah, I couldn't get over the bashing either. 
> 
> He came up with a way of counting huge counts without exceeding the
> write cycles of the EEPROM he's using. 
> 
> He shared it - and everyone hits him for the huge potential count it can
> do. 
> 
> The fact that it does considerably more than he is likely to need is
> surely neither here nor there. The technique may be useful to someone
> else.

Thank you, Alan! That was nice, for a change :)  

Ok, here's a summary, from my angle... (The items are in no specific order.
The numbers are just to separate items.)


1- I may not need 20M+ counts (I never said I did, it's not a
"specification", and I certainly did not "design against it"), but it
happens that the method supports it, so I stated so. I needed /some/ method
to count more than the guaranteed write count (100k). In my case the
possibly excessive count was for free (just setting a constant in the code
so that the counters filled the available EEPROM), so why limit myself to
less and miss the thrill to see a unit in 20 years with a 15M shift count
and still going, working with the third transmission? It wasn't making
anybody's life any "harder".

2- There may be other applications (where 20M+ really are needed) that
could use a similar technique. That was the real purpose of my post, and it
seems most of the posters have missed it (Alan didn't :). Hopefully not
most of the others :)

3- All the supposedly "better" methods suggested the use of "a few extra
components" (e.g. 0.5 F caps, FRAM devices) and a change to the PCB. Nobody
even tried to explain what the benefit (for the application) of the added
cost is. The (for other reasons, and prior to this counter implementation)
selected micro has an EEPROM, and it's big enough for my 20M counter... In
fact, that's the reason for the 20M+: I just set the index limit so that it
fills the available EEPROM. 

A funny side line is that the only stated added benefit of such an added
device (FRAM) was that it supports 10G writes -- being that the device was
suggested because designing for 20M counts was considered excessive. Now
talk about consistency in argumentation... When I have an application where
I need to design a persistent counter for 10G counts, I make sure to
consider FRAM (or another method), but until then I stay with the 20M+ that
I know I won't really need, thank you :)

4- One thing I forgot telling is that I set a flag whenever the index gets
incremented that causes an EEPROM refresh on the next power-up. This is
(again) a bit on the safe side... I hope nobody takes offense in this
safety margin :)

5- David contributed another suggestion: write until the read-back is
wrong. While this probably gets a higher number of writes out of a cell,
I'm not sure this is safe... couldn't it be that the cell reads back ok
right after the write, but not, say, after the next power cycle? 

What David didn't say is how he manages to multiply the count. The "trick"
of my suggestion is to use a 3 or 4 byte counter that moves over by one
byte at every 100k counts. Maybe obvious, maybe not, but it seems to me
that this is the most efficient way to have a persistent counter for large
counts in EEPROM -- for whatever reason you might need it. 

Thanks for your thoughts,
Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist