Searching \ for 'TMR0' 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/index.htm?key=tmr0
Search entire site for: 'TMR0'.

Truncated match.
PICList Thread
'TMR0'
1997\03\27@061946 by David BALDWIN

flavicon
face
I found in the 16C84 datasheet that when loading the TMR0 with a value,
we have to wait two cycles for it to synchronise. Do we have to reload
the TMR0 with a new value (the same in this case) each time it rolls
over 0? If I remember, this is not needed with the Intel 8051?

Thanks

-david

1997\03\27@074059 by Philippe

flavicon
face
At 12:12 27/03/1997 +0100, you wrote:
>I found in the 16C84 datasheet that when loading the TMR0 with a value,
>we have to wait two cycles for it to synchronise. Do we have to reload
>the TMR0 with a new value (the same in this case) each time it rolls
>over 0? If I remember, this is not needed with the Intel 8051?
>

## 2 cycles delay is normal, check carrefully the MICROCHIP data sheet
all is explain inside

## Yes you have to reload the TMR0 register each time it reach 00, against
8051 wich have AUTO-RELOAD timer, 16C84 doesn't have and simply count
from the initial value.

Best regards,

       Philippe.

 +---------------------------------------------------------+
 |   Virtual Micro Design                                  |
 | Try the Universal Simulator: UMPS                       |
 | E-Mail:  spam_OUTp.techerTakeThisOuTspamidls.izarbel.tm.fr                    |
 | WEB:     http://idls.izarbel.tm.fr/entp/techer/P01.HTM  |
 +---------------------------------------------------------+

1997\03\27@081456 by Andy Kunz

flavicon
face
At 12:12 PM 3/27/97 +0100, you wrote:
>I found in the 16C84 datasheet that when loading the TMR0 with a value,
>we have to wait two cycles for it to synchronise. Do we have to reload
>the TMR0 with a new value (the same in this case) each time it rolls
>over 0? If I remember, this is not needed with the Intel 8051?

You wait only when you reload it.  It wraps around 0 just fine all by
itself, no inserted delays.

If you have the prescaler assigned to the RTCC, I forget if it waits 2
prescaled or unprescaled, but it seems that it's only 2 unprescaled, ie, 8
ticks of the incoming oscillator (2uS at 4MHz).

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\03\27@120123 by Andrew Warren

face
flavicon
face
David BALDWIN <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU> wrote:

> I found in the 16C84 datasheet that when loading the TMR0 with a
> value, we have to wait two cycles for it to synchronise. Do we have
> to reload the TMR0 with a new value (the same in this case) each
> time it rolls over 0?

   No.

   -Andy

=== Andrew Warren - fastfwdspamKILLspamix.netcom.com
=== Fast Forward Engineering, Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\03\27@121556 by Andrew Warren

face
flavicon
face
David BALDWIN <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU> wrote:

> > I found in the 16C84 datasheet that when loading the TMR0 with a
> > value, we have to wait two cycles for it to synchronise. Do we
> > have to reload the TMR0 with a new value (the same in this case)
> > each time it rolls over 0?

   I replied, "No," but reading Philippe Techer's response leads me
   to believe that I misunderstood the question.

   David:  Did you mean, "If I load TMR0 with, say, 50 and let it
   count up to 0, do I have to reload it with 50 if I want it to
   repeat the sequence?"?

   If that's what you meant, the answer's yes.

   -Andy

=== Andrew Warren - EraseMEfastfwdspam_OUTspamTakeThisOuTix.netcom.com
=== Fast Forward Engineering, Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\03\27@121608 by Andrew Warren

face
flavicon
face
Andy Kunz <PICLISTspamspam_OUTMITVMA.MIT.EDU> wrote:

> If you have the prescaler assigned to the RTCC, I forget if it
> waits 2 prescaled or unprescaled [cycles to synchronize], but it
> seems that it's only 2 unprescaled, ie, 8 ticks of the incoming
> oscillator (2uS at 4MHz).

   Correct... And it's important to remember, also, that the
   prescaler is cleared on any write to RTCC/TMR0.

   So I don't have to explain it later, I should point out that
   "the prescaler is cleared" does NOT mean that the prescaler
   divide-by-ratio (set by OPTION bits Ps0-3) is changed; it only
   menas that the current prescaler count is set to 0.

   -Andy

=== Andrew Warren - @spam@fastfwdKILLspamspamix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html

1997\03\27@130057 by Bob Blick

flavicon
face
At 09:19 AM 3/27/97 -0800, you wrote:
>
>    David:  Did you mean, "If I load TMR0 with, say, 50 and let it
>    count up to 0, do I have to reload it with 50 if I want it to
>    repeat the sequence?"?
>
>    If that's what you meant, the answer's yes.

Would it also be OK to add 50 to it, in case you might have been busy with
something else and it advanced to 1. I know I'm not explaining myself very
well, I hope you understand what I mean :-)

-Bob

http://www.bobblick.com/

1997\03\27@132550 by Andrew Warren

face
flavicon
face
Bob Blick <KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU> wrote:

> >    David:  Did you mean, "If I load TMR0 with, say, 50 and let it
> >    count up to 0, do I have to reload it with 50 if I want it to
> >    repeat the sequence?"?
> >
> >    If that's what you meant, the answer's yes.
>
> Would it also be OK to add 50 to it, in case you might have been
> busy with something else and it advanced to 1. I know I'm not
> explaining myself very well, I hope you understand what I mean :-)

Bob:

I understand exactly what you mean... In fact, adding to (or
subtracting from) TMR0 is the best way to reload it, for exactly the
reason you describe.

-Andy


=== Andrew Warren - RemoveMEfastfwdTakeThisOuTspamix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html

1997\03\27@141540 by Kalle Pihlajasaari

flavicon
face
Hi Bob, Andy,

> > Would it also be OK to add 50 to it, in case you might have been
> > busy with something else and it advanced to 1. I know I'm not
> > explaining myself very well, I hope you understand what I mean :-)
>
> I understand exactly what you mean... In fact, adding to (or
> subtracting from) TMR0 is the best way to reload it, for exactly the
> reason you describe.

If I am not mistaken, this 'benefit' would be almost lost if you
had other than a 1:1 prescaler as the prescaler value would be
cleared and lost.

I do make use of this technique for timing but the lost cycle/s
on the write to TMR0 need to be watched out for especially when
you use no prescaler.

Cheers
--
Kalle Pihlajasaari   spamBeGonekallespamBeGonespamip.co.za   http://www.ip.co.za/ip
Interface Products   P O Box 15775, DOORNFONTEIN, 2028, South Africa
+ 27 (11) 402-7750   Fax: 402-7751    http://www.ip.co.za/people/kalle

DonTronics, Silicon Studio and Wirz Electronics uP Product Dealer

1997\03\27@145834 by Andrew Warren

face
flavicon
face
Kalle Pihlajasaari <TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU> wrote:

> > adding to (or subtracting from) TMR0 is the best way to reload
> > it, for exactly the reason you describe.
>
> If I am not mistaken, this 'benefit' would be almost lost if you had
> other than a 1:1 prescaler as the prescaler value would be cleared
> and lost.

Kalle:

Yes and no.  It should be possible to write some clever code to
determine EXACTLY when the TMR0 register increments... Using that
code, you could reload TMR0 without losing the prescaler state.

I'm taking a lunch break anyway... Maybe I can come up with an
example.  Here:

   ; Enter this section with TMR0 between 128 and 255, inclusive,
   ; and the prescaler divide-by-ratio set to divide-by-4.

   WAITFOR0:

       BTFSC   TMR0,BIT7       ;WAIT FOR TMR0 TO OVERFLOW.
       GOTO    WAITFOR0        ;

   ; AT THIS POINT (SINCE OUR "WAITFOR0" LOOP HAS A RESOLUTION OF 3
   ; CYCLES), THE TMRO:PRESCALER REGISTERS CAN BE EQUAL TO ANY OF
   ; THE FOLLOWING COMBINATIONS:
   ;
   ;     TMRO  PRE
   ;      00    2
   ;      00    3
   ;      01    0

       BTFSS   TMR0,BIT0       ;IF TMR0 = 01, WASTE 2 CYCLES.
       GOTO    $+1             ;OTHERWISE, WASTE 3 CYCLES.

   ; AT THIS POINT, TMR0:PRE CAN ONLY BE EQUAL TO ONE OF THESE:
   ;
   ;     TMRO  PRE
   ;      01    1
   ;      01    2

       GOTO    $+1             ;WASTE TWO CYCLES.

   ; AT THIS POINT, TMR0:PRE CAN ONLY BE EQUAL TO ONE OF THESE:
   ;
   ;     TMRO  PRE
   ;      01    3
   ;      02    0

       BTFSS   TMR0,BIT1       ;IF TMR0 = 02, WASTE 2 CYCLES.
       GOTO    $+1             ;OTHERWISE, WASTE 3 CYCLES.

   ; AT THIS POINT, TMR0:PRE CAN ONLY BE EQUAL TO:
   ;
   ;     TMRO  PRE
   ;      02    2

       GOTO    $+1              ;WASTE TWO CYCLES.

   ; TMR0 ALWAYS INCREMENTS FROM 02 TO 03 RIGHT HERE.

       MOVLW   RELOAD+4         ;RELOAD TMR0.  WE NEED TO ADD 4 TO
       MOVWF   TMR0             ;THE RELOAD VALUE BECAUSE THESE TWO
                                ;INSTRUCTIONS TAKE 2 CYCLES TO
                                ;EXECUTE AND THERE'S AN ADDITIONAL
                                ;2-CYCLE SYNCHRONIZATION DELAY.
                                ;WHEN TMR0 STARTS INCREMENTING
                                ;AGAIN, IT WILL BE AT -EXACTLY- THE
                                ;MOMENT THAT TMRO:PRE WOULD HAVE
                                ;ROLLED FROM 03:3 TO 04:0.

Of course, I haven't tested the above code -- I just typed it into
this message, so it may have bugs -- but you get the idea.  Similar
code can be written for any porescaler divide-by ratio.

-Andy

=== Andrew Warren - RemoveMEfastfwdspamTakeThisOuTix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Did the information in this post help you?  Consider
=== contributing to the PICLIST Fund.  Details are at:
=== www.geocities.com/SiliconValley/2499/fund.html

1997\03\27@150744 by Ed Todd

picon face
You can do all sorts of TMR0/RTCC stuff.  On one application, I use TMR0 to
synchronize data capture with distortions, and do resync arithmetic under
certain conditions:
       MOVLW   IDEALVALUE              ; theoretical value
       SUBWF   RTCC,W          ; error
       SUBWF   RTCC,F                  ; adjust clock by error
Works fine.
 <edtoddEraseMEspam.....sni.net>    Ed Todd

1997\03\27@151116 by Bob Blick

flavicon
face
>> > Would it also be OK to add 50 to it, in case you might have been
>> > busy with something else and it advanced to 1. I know I'm not
>> > explaining myself very well, I hope you understand what I mean :-)
>>
>> I understand exactly what you mean... In fact, adding to (or
>> subtracting from) TMR0 is the best way to reload it, for exactly the
>> reason you describe.
>
>If I am not mistaken, this 'benefit' would be almost lost if you
>had other than a 1:1 prescaler as the prescaler value would be
>cleared and lost.
>
>I do make use of this technique for timing but the lost cycle/s
>on the write to TMR0 need to be watched out for especially when
>you use no prescaler.

So the idea would be:

If the prescaler is used, never to do any writes to TMR0 if you wish to
preserve the accuracy of continuous timing(I'm thinking propeller clock
here, of course), just let the timer free run and keep track of your count
elsewhere.

If you are not using the prescaler, use the add-to-TMR0 method(which is
when you'd most likely need it anyway, since you'd certainly miss some
counts, and not a predictable number of them, since interrupt response time
varies)?

Does that seem like a useful rule of thumb?

Or is TMR0 possibly advanced while you are in the process of adding to it?

-Bob

http://www.bobblick.com/

1997\03\27@154304 by Andrew Warren

face
flavicon
face
Bob Blick <EraseMEPICLISTspamMITVMA.MIT.EDU> wrote:

> So the idea would be:
>
> If the prescaler is used, never to do any writes to TMR0 if you wish
> to preserve the accuracy of continuous timing(I'm thinking propeller
> clock here, of course), just let the timer free run and keep track
> of your count elsewhere.

   Yes, unless you want to go to the trouble of synchronizing the
   prescaler using code like the example I posted.

> If you are not using the prescaler, use the add-to-TMR0
> method(which is when you'd most likely need it anyway, since you'd
> certainly miss some counts, and not a predictable number of them,
> since interrupt response time varies)?

   Yes, or just let it free-run anyway and handle it as above.

> Does that seem like a useful rule of thumb?

   Yes.

> Or is TMR0 possibly advanced while you are in the process of
> adding to it?

   TMR0 (and/or its prescaler) is DEFINITELY advanced while you're
   writing to it, so you need to make allowances for that.  The
   easiest way, in general, is to just make a rough guess as to the
   reload value, then fine-tune that value by observing the
   program's behavior on a scope.

   -Andy

=== Andrew Warren - RemoveMEfastfwdEraseMEspamEraseMEix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html

1997\03\27@193913 by Andy Kunz

flavicon
face
>If the prescaler is used, never to do any writes to TMR0 if you wish to
>preserve the accuracy of continuous timing(I'm thinking propeller clock
>here, of course), just let the timer free run and keep track of your count
>elsewhere.
>
>If you are not using the prescaler, use the add-to-TMR0 method(which is
>when you'd most likely need it anyway, since you'd certainly miss some
>counts, and not a predictable number of them, since interrupt response time
>varies)?

Bob,

I prefer to do something like the following:


MainLoop

       movf    TriggerPoint,W
       xorwf   TMR0,W
       btfss   Z
       goto    NoMatch
Match
       ... process the timer match condition
       movlw   TimerIncrement
       addwf   TriggerPoint,F
       goto    MeetAgain
NoMatch
       ... do whatever if they don't match
MeetAgain
       ... whatever


Hope that helps a little.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\03\28@065734 by Mike Smith

flavicon
face
> ## Yes you have to reload the TMR0 register each time it reach 00,
against
> 8051 wich have AUTO-RELOAD timer, 16C84 doesn't have and simply count
> from the initial value.

Which is a good reason to put the reload code into the ISR, and have it
happen automagically.

MikeS

1997\03\28@072224 by David BALDWIN

flavicon
face
What's the ISR?

1997\03\28@074436 by n/a

flavicon
face
David BALDWIN wrote:
>
> What's the ISR?

(I hope your asking for the definition of ISR and not for some code
for the ISR).

Interrupt Service Routine.

--
Neil Cherry

If you need to contact me via email please use this email address to
respond: RemoveMEncherryspam_OUTspamKILLspamworldnet.att.net

1997\03\28@075457 by David BALDWIN

flavicon
face
Mike Smith wrote:
>
> > ## Yes you have to reload the TMR0 register each time it reach 00,
> against
> > 8051 wich have AUTO-RELOAD timer, 16C84 doesn't have and simply count
> > from the initial value.
>
> Which is a good reason to put the reload code into the ISR, and have it
> happen automagically.
>
> MikeS


       Ok, but if I had like to have interruptions to occur each 10ms, while
using the prescaler, it's not easy, if I have to keep time, for inst.

--

 _____________
 \           /               David BALDWIN
  \ ALCATEL /               Design engineer
   \TELECOM/
    \     /         SdM (Societe de Microelectronique)
     \   /
      \ /      B.P. 4205            Phone : +32 (0)71 442932
       V       B-6000 Charleroi     Fax   : +32 (0)71 442905
               (Belgium)            RemoveMEbaldwinTakeThisOuTspamspametca.alcatel.be

1997\03\29@001543 by Mike Smith

flavicon
face
> > > ## Yes you have to reload the TMR0 register each time it reach 00,
> > against
> > > 8051 wich have AUTO-RELOAD timer, 16C84 doesn't have and simply count
> > > from the initial value.
> >
> > Which is a good reason to put the reload code into the ISR, and have it
> > happen automagically.
> >
>
>         Ok, but if I had like to have interruptions to occur each 10ms,
while
> using the prescaler, it's not easy, if I have to keep time, for inst.
>
If I want to do that, I just put a routine in that increments a 16 or 32
bit variable by  10mS every interrupt, then use that value for the RTC (or
inc by 1, and mult by 10 when reading it, preferably)

MikeS

1997\03\31@221758 by ns

flavicon
face
On Fri, 28 Mar 1997, David BALDWIN wrote:

> What's the ISR?
>

ISR = ISR Service Routine


'TMR0'
1997\04\01@201305 by Steve Hardy
flavicon
face
> From: Andrew Warren <EraseMEfastfwdspamspamspamBeGoneIX.NETCOM.COM>
> [cut]
> > Or is TMR0 possibly advanced while you are in the process of
> > adding to it?
>
>     TMR0 (and/or its prescaler) is DEFINITELY advanced while you're
>     writing to it, so you need to make allowances for that.  The
>     easiest way, in general, is to just make a rough guess as to the
>     reload value, then fine-tune that value by observing the
>     program's behavior on a scope.

This harks back to one of my first PICLIST postings.  One can be
entirely scientific about setting TMR0 to be a period counter
other than 256.  This is one way to do it, but assumes the
prescaler is not being used.  If the prescaler is being used,
this technique is still useful if one ensures that there is a
constant number of cycles of execution between the start of the
interrupt handler and the clock advance.  Read that as 'put clock
advance at start of interrupt routine', folks.  If this is done,
then the interrupt gets fired off at exact intervals (no jitter).
If the prescaler is used, the '259' constant should be reduced to
257 for a prescale of 2, and 256 for all other prescales.  Also,
and this gets really tricky, the actual period obtained will
depend on the number of instructions executed since the start of
interrupt, since the prescaler 'remainder' (which gets truncated
when the clock is advanced) will depend on this.

CYCLES  equ     50      ; Desired TMR0 period

       org     4       ; interrupt routine
       ...             ; save status and anything else
; Advance clock so we get back here in exactly CYCLES instructions
; Subtract desired interval from 259 (not 256) to compensate for clock
; restart delay.  Since this is the nth cycle since the clock ticked over,
; CYCLES must not be greater than 259+n to avoid interrupt race condition.
; CYCLES must not be less than the maximum required for interrupt service
; plus a little extra for useful (non-interrupt) work, for the same reason.
; Note diff between simulator and real device!
       movlw   259-CYCLES      ; 259 for real device, 258 for mpsim.
       addwf   tmr0,f          ; Wind clock forward (daylight saving?)
       ...
       retfi


Regards,
SJH
Canberra, Australia

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