I have a task, where I have to build a operation time counter, means
somethings, which adds the time a device was switched on. There is only a 5V
DC supply, if 5V is present the device works, if not, the device is switched
off.
The total time to be checked is 5 years and the resolution has to be 1
minute.
Now first the task is very simple: When the PIC (I intend to use a 12F629)
is powered up, it reads the already elapsed time from EEPROM, then simply
starts to count minutes (by TMR1 and an added software divider) and when a
minute is over it stores the new total time into EEPROM.
Now the problem is, when calculating the total number of storages you'll get
5 years x 365 days x 24 hours x 60 minutes = about 2,6 x 10E6 write cycles,
but the spec only says 10E6 cycles for EEPROM memory.
Further thinking showed that the result is never bigger than 3 Bytes
(FFFFF&h = 16,7 x 10E6) and the high and middle byte can be stored only, if
they have changed, so I have no more than 2,6x10E6 / 256 = about 10000 write
cycles for the middle byte and even 2,6x10E6 / 65536 = 40 write cycles for
the high byte which is inside spec.
The problem is to find a way to store 2,6x10E6 time one byte into EEPROM.
Has anybody an idea? Any help greatly appreciated!
> The total time to be checked is 5 years and the resolution has to be 1
> minute.
You simply won't get that accuracy over 5 years with a PIC's TMR. An
external timing source is needed
> Now first the task is very simple: When the PIC (I intend to use a
> 12F629) is powered up, it reads the already elapsed time from
> EEPROM, then simply starts to count minutes (by TMR1 and an
> added software divider) and when a minute is over it stores the new
> total time into EEPROM.
What about partial minutes ? If power-up/power-down is frequent
you'll lose a lot of combined time. Which affects the above accuracy
of course
> Now the problem is, when calculating the total number of storages
> you'll get 5 years x 365 days x 24 hours x 60 minutes = about 2,6
> x 10E6 write cycles, but the spec only says 10E6 cycles for
> EEPROM memory.
See the thread
[PIC] Count 20M+ in EEPROM counter
from mid-January 2006
You might want to consider not writing to EEPROM every minute but
holding the PIC's Vcc for a while up with a cap after power-down so
that the most recent value (stored in RAM) can be written
>-----Original Message-----
>From: spam_OUTpiclist-bouncesTakeThisOuTmit.edu [.....piclist-bouncesKILLspam@spam@mit.edu]
>Sent: 31 May 2006 08:07
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] operation time counter
>
>
>Hi Peter, some comments
>
>> The total time to be checked is 5 years and the resolution
>has to be 1
>> minute.
>
>You simply won't get that accuracy over 5 years with a PIC's
>TMR. An external timing source is needed
>
AFAICT the OP only requires a resolution of 1 minute, not an accuracy of 1 minute in 5 years which would be pretty much impossible to achieve with a normal quartz crystal.
There was a fairly recent thread on spreading out writes over the EEPROM to maximise endurance, a search of the archives should find it.
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.
=======================================================================
> > > The total time to be checked is 5 years and the resolution
> > > has to be 1 minute.
> >
> >You simply won't get that accuracy over 5 years with a PIC's
> >TMR. An external timing source is needed
> >
> AFAICT the OP only requires a resolution of 1 minute, not an accuracy
> of 1 minute in 5 years
Hi Mike, if that were the case then the "5 years" is irrelevant. You may
as well take the reading for the day and start afresh
> There was a fairly recent thread on spreading out writes over
> the EEPROM to maximise endurance, a search of the archives
> should find it
Apart from the thread I mentioned, Bob Axtell has outlined his
method a couple of times
Sent: Friday, December 17, 2004 7:22 AM
Subject: Re: [PIC] EEPROM Limits on a PIC18LF248
> So, what I do is to write the variable in 3 places. When I read it
> next time, I read all three and see if they compare, taking the best
> two out of three, but in any case, I have to write all three anyway.
> This assures accuracy, as the chance that more than one will exhibit
> failure is unlikely in 1-2 seconds
>
> --Bob
Jinx wrote:
>> The total time to be checked is 5 years and the resolution has to be 1
>> minute.
>
> You simply won't get that accuracy over 5 years with a PIC's TMR. An
> external timing source is needed
Not according to the provided spec. The OP said nothing about accuracy.
******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC
consultant in 2004 program year. http://www.embedinc.com/products
>-----Original Message-----
>From: piclist-bouncesKILLspammit.edu [.....piclist-bouncesKILLspam.....mit.edu]
>Sent: 31 May 2006 11:34
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] operation time counter
>
>
>> > > The total time to be checked is 5 years and the resolution
>> > > has to be 1 minute.
>> >
>> >You simply won't get that accuracy over 5 years with a PIC's
>> >TMR. An external timing source is needed
>> >
>> AFAICT the OP only requires a resolution of 1 minute, not an
>accuracy
>> of 1 minute in 5 years
>
>Hi Mike, if that were the case then the "5 years" is
>irrelevant. You may as well take the reading for the day and
>start afresh
Joe,
It's only relevant in that it determines the maximum counter size required, i.e. the number of cells in the EEPROM which need to be updated. 5 years is 2630880 minutes which will comfortably fit into 3 bytes which IIRC is the size counter that Bob was using?
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.
=======================================================================
> It's only relevant in that it determines the maximum counter size
> required, i.e. the number of cells in the EEPROM which need
> to be updated. 5 years is 2630880 minutes which will
> comfortably fit into 3 bytes which IIRC is the size counter that
> Bob was using?
Yeeup, I see that now. The gun went off and I ran the wrong way
You'll generally see these commercially as "hourmeters" or "Hobbs meters" in
small aircraft, commercial trucks, and other industrial apps.
As previously mentioned, there are previous threads that do a pretty good job
of discussing the EEPROM storage, and it sounds like you'll have to (or
should) use an external EEPROM. You should spread the data across multiple
areas in the EEPROM, and on power-up, just search for the highest-valued set.
But you also need to realize that since each value is 3 bytes, what happens if
power is cut-off in the middle of saving a 3-byte set? Or perhaps one of 3
bytes fails? You'll notice the problem when power comes back on. Chance of
this happening? Very possible, especially over 5 years. In my app, I wrote
all bytes of a set all the time, but then save that same data three times to
different areas of memory. On power-up, I cross-check all 3 sets to verify
it's validity. Sort of like a RAID system. I also flipped some bits in some
of the copies, just in case the EEPROM had some failure mode where all bits
might go to ones or zeros.
Another possibility would be to have a special "control" byte for each set,
where you would set that to some value to indicate that that set was "dirty",
then write all 3 bytes of the set, then verify the data by reading it back,
and if all is okay, go ahead and mark the control byte as valid. On
power-up, search for all the valid sets only.
Cheers,
-Neil.
On Wednesday 31 May 2006 01:24, Peter Feucht wrote: {Quote hidden}
> Dear PICCERs,
>
> I have a task, where I have to build a operation time counter, means
> somethings, which adds the time a device was switched on. There is only a
> 5V DC supply, if 5V is present the device works, if not, the device is
> switched off.
> The total time to be checked is 5 years and the resolution has to be 1
> minute.
> Now first the task is very simple: When the PIC (I intend to use a 12F629)
> is powered up, it reads the already elapsed time from EEPROM, then simply
> starts to count minutes (by TMR1 and an added software divider) and when a
> minute is over it stores the new total time into EEPROM.
> Now the problem is, when calculating the total number of storages you'll
> get 5 years x 365 days x 24 hours x 60 minutes = about 2,6 x 10E6 write
> cycles, but the spec only says 10E6 cycles for EEPROM memory.
> Further thinking showed that the result is never bigger than 3 Bytes
> (FFFFF&h = 16,7 x 10E6) and the high and middle byte can be stored only, if
> they have changed, so I have no more than 2,6x10E6 / 256 = about 10000
> write cycles for the middle byte and even 2,6x10E6 / 65536 = 40 write
> cycles for the high byte which is inside spec.
> The problem is to find a way to store 2,6x10E6 time one byte into EEPROM.
>
> Has anybody an idea? Any help greatly appreciated!
>
>
> Best regards
>
> Peter
mit.edu [.....piclist-bouncesKILLspam
