Lawrence:

Thanks for the great info.  The accuracy of my timing is in seconds...and
it doesn't even have to be that accurate.  I need to time intervals in the
range of minutes (probably around 2), before my device moves onto the next
state.

What clock rate are you using? 4Mhz? If so, what is the longest duration
you can set before a timer interrupt?  I'm using the 18F452.

Here's my attempt to answer my own questions.

Timer0 can be either 8 or 16 bits.  So I think I want 16 bits...and the
largest prescalar is 256.
OK...so if I use a 4Mhz clock...

-16 bits counts to 65,535.
-with a prescalar of 256, it means that for every 256 clock "tick", the
timer ticks 1 (I think this is right)
-so with the prescalar, the interrupt happens every 65535*256 = 16,776,960
clock "ticks".

-with a 4Mhz clock, a clock "tick" happens every 0.00000025 seconds.

-so 16,776,960 * 0.00000025 = 4.194 seconds (this is the approximate time
for each timer interrupt).

Is this math (and all of my assumptions above) right?

-James



At 07:04 AM 5/21/2004, you wrote:
>James,
>
>This is a real common thing to try - there should be lots of good examples
>on PIClist.com.
>
>90% of my projects run with this architecture:
>
>I will usually have a timer interrupt that goes off some fraction of a
>second, and count them.  Say 0.1 seconds.
>Every 10 interrupts I will set a flag, or else increment a variable called
>"secondscounter".  The timer interrupt does little else but keep track of
>time.  I usually code in C, which has a bit of overhead at each interrupt,
>so I will often hand-calibrate a timer interrupt in a simulator or in a
>real PIC to make sure the timer interrupt is accurate enough.
>
>The rest of the application simply runs in a superloop.  If a subroutine
>needs to know what time it is, secondscounter is always available.  Say it
>is a timer for a baking cycle.  The user presses a button to start a
>baking cycle, secondscounter is set to zero.  Every time through the
>superloop, the bake subroutine looks at the time and decides if it is time
>to shut off yet.
>
>I never need to know timing closer than one second.  This architecture
>would be inaccurate for sub-second timing and useless for millisecond
>timing.  Probably also inaccurate for timing longer than 24 hours.  But it
>is great for keeping track of a few minutes with one second accuracy.
>
>BTW, what kind of projects are you designing?  From your email I assume it
>is with a toy manufacturer?
>
>
>-- Lawrence Lile
>
>
>
>
>
>"M. Adam Davis" <adampic@UBASICS.COM>
>Sent by: pic microcontroller discussion list <PICLIST@MITVMA.MIT.EDU>
>05/20/2004 03:18 PM
>Please respond to pic microcontroller discussion list
>
>
>         To:     PICLIST@MITVMA.MIT.EDU
>         cc:
>         Subject:        Re: [PIC:]  Timing intervals (in the range of
> minutes)
>
>
>It depends on how accurate the intervals need to be.  Generally, though,
>I'd use one of the 16bit timers with prescaler and a slow 32kHz
>crystal.  It needs to have an interrupt which will wake the processor
>from sleep.
>
>-Adam
>
>James Tu wrote:
>
> > What is the best way to use the PIC to time intervals.  I basically
> > want to
> > create a state machine and want it to be partially driven by time and
> > partially driven by user input.
> >
> >
> > James Tu
> > james@2-bit-toys.com
> >
> > --
> > http://www.piclist.com hint: To leave the PICList
> > mailto:piclist-unsubscribe-request@mitvma.mit.edu
> >
> >
> >
>
>--
>http://www.piclist.com hint: To leave the PICList
>mailto:piclist-unsubscribe-request@mitvma.mit.edu
>
>
>
>--
>http://www.piclist.com hint: PICList Posts must start with ONE topic:
>[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

James Tu
james@2-bit-toys.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.