>-----Original Message-----
>From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] 
>Sent: 19 January 2006 12:29
>To: piclist@mit.edu
>Subject: Re: [PIC] Count 20M+ in EEPROM counter
>
>
>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")

Sorry, but in your first post you said "I needed to count some 20M+ incidents".  From most peoples point of view, that sounds very much like a design specification.  You may feel it's being pedantic to argue about this, but if you really only needed to measure, say 500k events, perhaps some valid alternatives could have been suggested.

>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. 

The advtange of an FRAM (and I'm absolutely sure this was stated) is that is has no wait time on writes, and has infinite (to all intents and purposes) endurance.  If neither of those are important, then obviously the higher cost is not justifiable.

I searched through the posts in this topic and couldn't find any mention of 0.5 F caps apart from your post.  The size of cap required to complete an EEPROM write would be much smaller than this, bearing in mind the PIC would only need to keep running for ~20ms absolute worst case (three cells for the counter and the index cell).  Quick calculation shows a capacitance in the 10's of uF range would probably suffice, especialy if you have a low power nano-watt PIC.  It's a very relevant discussion anyway, as writes to EEPROM are vulnerable to corruption during brown out events.  If this occured whilst you were writting your index byte, it could mean you start re-using one of the previous cells that has already suffered ~100k writes.


>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 :)

In that case the safety margin depends on a condition which you presumably have no real control over, the time between power up events, and the number of gearchanges.  Clearly this will almost certainly be ok, in the same way that almost certainly you won't be recording 20M events in 10 years ;)

>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. 

FWIW I do think it's a neat trick, it maximises the endurance of every cell used in the counter without any being wasted.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

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