Searching \ for '[PIC]:Accurate 1sec counter from system 4-20MHz cl' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/time.htm?key=count
Search entire site for: 'Accurate 1sec counter from system 4-20MHz cl'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:Accurate 1sec counter from system 4-20MHz cl'
2003\04\11@100844 by Mccauley, Daniel H

flavicon
face
I tried searching the archives for this one, but every listing concentrated
around a 32.768kHz oscillator source.

Anyways, my PIC application will require an accurate 1 second internal
counter for timing, but does require a system clock speed of 4-20Mhz.

I was planning on using a PIC16C66 microcontroller which allows the use of a
second oscillator at RC0 and RC1 set at 32.768kHz, but I am looking towards
possibly using a small PIC device that doesn't have this feature.

Any thoughts on how to utilize a second counter using the 4+MHz system
clock???

Thanks

Dan

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu>

2003\04\11@111433 by Dale Botkin

flavicon
face
On Fri, 11 Apr 2003, Mccauley, Daniel H wrote:

> Anyways, my PIC application will require an accurate 1 second internal
> counter for timing, but does require a system clock speed of 4-20Mhz.

Look in the archives for the thread, "[PIC]: simple one-second timer".
Roman and Bob (Blick, I think it was) came up with a method I have used in
numerous projects.  I can post C code for my implementation of it, but
that's in the archives too from a few months ago.

Dale
--
It's a thankless job, but I've got a lot of Karma to burn off.

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu>

2003\04\11@120605 by Hazelwood Lyle

flavicon
face
>> Anyways, my PIC application will require an accurate 1 second internal
>> counter for timing, but does require a system clock speed of 4-20Mhz.
>
>Look in the archives for the thread, "[PIC]: simple one-second timer".
>Roman and Bob (Blick, I think it was) came up with a method I have used in
>numerous projects.  I can post C code for my implementation of it, but
>that's in the archives too from a few months ago.

I believe that Roman has also posted some of this on his website.
http://www.romanblack.com/one_sec.htm

Lyle

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu>

2003\04\11@134517 by Jai Dhar

flavicon
face
I just want to say that after reading Roman's page, I was thoroughly impressed
with it!!! Good work Roman :-)

Simple question though, and I think the answer is obvious. The "zero long term
error" point is assuming the crystal (or whatever is used) doesn't vary over
time and acts perfectly, correct? Or does this take that into account?

Quoting Hazelwood Lyle <.....LHazelwoodKILLspamspam.....MFGNC.COM>:

{Quote hidden}

----------------------------------------
This mail sent through http://www.mywaterloo.ca

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu>

2003\04\11@135522 by Mccauley, Daniel H

flavicon
face
I realize this is "zero long term error", but what would be the error during
short durations.  For example, what is the error per second for say a 5-10
second duration.  My application will require resolution to 0.001 sec for
about 5 to 10 seconds at which distance data will be plotted against time.
The actual "second period" created by my microcontroller only has to be
within +/- 1% of the actual scientific "Unit Second", but it has to be
accurate from second to second over that 5 to 10 seconds.

Thanks
Dan



{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu>

2003\04\11@135728 by Hazelwood Lyle

flavicon
face
From: Jai Dhar [TakeThisOuTjdharEraseMEspamspam_OUTENGMAIL.UWATERLOO.CA]

>I just want to say that after reading Roman's page, I was thoroughly impressed
>with it!!! Good work Roman :-)
>
>Simple question though, and I think the answer is obvious. The "zero long term
>error" point is assuming the crystal (or whatever is used) doesn't vary over
>time and acts perfectly, correct? Or does this take that into account?

This is correct.

You might want to periodically "fudge" the numbers if you want to fine tune
your board for a particular environment(and temperature). This may be suitable
for a "one off", but I doubt you'd want to do this for a production item.

If you need more accuracy, you might have to find an external time source
to make corrections with. There have been many discussions about this on
the list, check the archives for more info.

As far as I can tell, we haven't seen Roman here for a while. I have a few
more questions about the Black regulator for him.

Wherever he is, I wish him well.

Lyle



{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu>

2003\04\11@135940 by Marc Nicholas

flavicon
face
You're asking how much 'jitter' there will be?

-marc

On 11/4/03 13:54, "Mccauley, Daniel H" <EraseMEdaniel.h.mccauleyspamLMCO.COM> wrote:

{Quote hidden}

--------------------------------------------------
Marc Nicholas Geekythings Inc. C/416.543.4896
UNIX, Database, Security and Networking Consulting

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspammitvma.mit.edu>

2003\04\11@143024 by Dwayne Reid

flavicon
face
At 01:54 PM 4/11/03 -0400, Mccauley, Daniel H wrote:
>I realize this is "zero long term error", but what would be the error during
>short durations.  For example, what is the error per second for say a 5-10
>second duration.  My application will require resolution to 0.001 sec for
>about 5 to 10 seconds at which distance data will be plotted against time.
>The actual "second period" created by my microcontroller only has to be
>within +/- 1% of the actual scientific "Unit Second", but it has to be
>accurate from second to second over that 5 to 10 seconds.

There can be significant short term error.  The implementation I use
(generates 0.100 sec ticks from 1.024 ms ticks) has 8 bits of jitter (1.024
ms).  This is entirely adequate for my purposes but I'm sure that it is not
suitable for yours.

The bottom line is that the jitter period is equal to your update
period.  If you update every 256us, you will have up to 256us jitter.  If
you opt for a PIC running at 20 MHz with TMR0 rollover every 256 cycles, it
can be 5 times better than that.

As I type this, I'm beginning to think that what you really need to do is
to pick a crystal frequency that divides down to the time-base you need
with zero error.  You have a lot of choices, ranging from 32 KHz watch
crystal, on up to any crystal that is a power of 2 multiple (4.096 MHz
gives you exactly 1ms ticks when TMR0 prescale is set for /4).

dwayne

--
Dwayne Reid   <dwaynerSTOPspamspamspam_OUTplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 19 years of Engineering Innovation (1984 - 2003)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestSTOPspamspamEraseMEmitvma.mit.edu>

2003\04\11@163931 by Olin Lathrop

face picon face
> Any thoughts on how to utilize a second counter using the 4+MHz system
> clock???

Divide it down to some convenient period, like 10mS, using timer 2, then
divide the rest of the way in software.  If you can keep the timer 2
period above 4mS, then you only need an 8 bit counter to get whole
seconds.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu>

2003\04\11@193515 by Jinx

face picon face
> I tried searching the archives for this one, but every listing
> concentrated around a 32.768kHz oscillator source.

I'm surprised at that. 1 second timer is a perennial subject and
has a pretty good and regular thrashing. Were you looking in
the resources or the mail archives ?

> Anyways, my PIC application will require an accurate 1 second
> internal counter for timing, but does require a system clock speed
> of 4-20Mhz.

Just choose a xtal that's hex (particularly a multiple of 1024) rather
than decimal, eg 4.096 not 4.000 or 10.240 not 10.000, 18.432 or
19.6608 rather than 20.000

Use timer rollover IRQs to increment RAM counters. For example, a
4.9152 xtal will generate (4915200 / 4 / 256) = 4800 TMR0 IRQs per
second (or fewer if the pre-scaler is used), and no worries about
fudging, jitter, reloading......  All you need to consider is the ppm
accuracy of the xtal, and maybe add a trimmer to fine-tune the
frequency

> As far as I can tell, we haven't seen Roman here for a while. I have
> a few more questions about the Black regulator for him.

> Wherever he is, I wish him well.

> Lyle

I talked to him a little while ago. Apparently he's off researching a
book about people's favourite boy bands

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamEraseMEmitvma.mit.edu>

2003\04\11@212502 by Bob Ammerman

picon face
The worst case error is always less than the amount of time per interrupt.

btw: It wasn't Bob Blick's idea, but another Bob's :-)

Bob Ammerman
RAm Systems

{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...