G, you still don't mention the size of your EEPROM.  I want to calculate the
efficiency of your algorithm versus mine for the fun of it.

I figure with a 1024B EEPROM, I could get 51.2M events.  But I have no idea
which EEPROM it is you're writing to.  I suppose I could try working it back
from what you're said, but hey, it's easier to just ask.  :-)


On 1/19/06, Gerhard Fiedler <lists@connectionbrazil.com> wrote:
>
> 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
>



--


Shawn Wilton (b9 Systems)
http://black9.com
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist