• AVR Freaks

Hot!TMR2

Author
ProfessorChaos
New Member
  • Total Posts : 20
  • Reward points : 0
  • Joined: 2019/01/15 09:40:47
  • Location: 0
  • Status: offline
2019/05/23 11:42:45 (permalink)
0

TMR2

Using the PIC18F8723. Want to use TMR2 to generate an interrupt every millisecond.
 
TMR2 = 0; // initialize
PR2 = 250; // 4 x 250 = 1000 instructions
T2CON = 0x01; // pre-scaler 4

i = INSTRUCTIONS_PER_MICROSECOND; // set up post-scaler
i--;
T2CONbits.TOUTPS = i & 0x0Fu;

IPR1bits.TMR2IP = 0; // low priority interrupt
PIR1bits.TMR2IF = 0; // clear interrupt flag
PIE1bits.TMR2IE = 1; // enable interrupt
T2CONbits.TMR2ON = 1; // TMR2 on

 
(INSTRUCTIONS_PER_MICROSECOND is a macro that divides _XTAL_FREQ / 4,000,000.)
Tried this code at 32mhz (internal oscillator) and 20mhz (HLL external oscillator) and toggled a pin in the interrupt handler. The scope measure 996hz rather than 1000hz.
 
After some faffing around, I changed the second line above to:
PR2 = 249;
and I saw 1000hz on the scope.
 
My assumption was that when TMR2 matched PR2, TMR2 was set back to zero on the next instruction but it doesn't look like it works that way. (In the device data sheet, it states: "This signal also resets the value of TMR2 to 00h on the
next cycle." However, in another MC document about TMR2 I found it uses the phrase "increment cycle.")
 
The only way that I can see the PR2 = 249 thing generates the correct timing is if the timer increments back to 0 in the normal way after a match, rather than immediately being set to 0 on a match. Is that in fact what happens?
 
#1

15 Replies Related Threads

    du00000001
    Just Some Member
    • Total Posts : 2890
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: TMR2 2019/05/23 11:48:01 (permalink)
    +1 (1)
    "On the next (increment) cycle":
    As the timer is clocked by 1/4 of the reference clock, the reset occurs 4 reference clock cycles after the match.
    Not unexpected - otherwise your period would be 1001 reference clock cycles...

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #2
    jtemples
    عُضْوٌ جَدِيد
    • Total Posts : 11248
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    Re: TMR2 2019/05/23 11:49:37 (permalink)
    +1 (1)
    The data sheet clearly states that the timer resets on the NEXT cycle after the match.
    #3
    ProfessorChaos
    New Member
    • Total Posts : 20
    • Reward points : 0
    • Joined: 2019/01/15 09:40:47
    • Location: 0
    • Status: offline
    Re: TMR2 2019/05/23 11:54:43 (permalink)
    0
    Ok, that's fine, but it actually appears (from the results I'm seeing on the scope) that it must not be going straight back to zero on the next instruction or I wouldn't be seeing 1000hz on the scope because it would be timing 996us (4 x 249) instead of 1ms per interrupt.
     
    It looks like it actually does a full cycle (pre/post scale and a match) before it goes back to zero.
     
    #4
    jtemples
    عُضْوٌ جَدِيد
    • Total Posts : 11248
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    Re: TMR2 2019/05/23 12:05:03 (permalink)
    +1 (1)
    They mean "clock cycle", not "instruction cycle", though that's not especially clear in the data sheet.
    #5
    mbrowning
    Just a Member
    • Total Posts : 1460
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: online
    Re: TMR2 2019/05/23 12:09:40 (permalink)
    +2 (2)
    From 0 to 249 is 250 numbers. You’re forgetting to count 0

    Oh well - there's always next year
    #6
    ProfessorChaos
    New Member
    • Total Posts : 20
    • Reward points : 0
    • Joined: 2019/01/15 09:40:47
    • Location: 0
    • Status: offline
    Re: TMR2 2019/05/23 12:13:44 (permalink)
    0
    mbrowning
    From 0 to 249 is 250 numbers. You’re forgetting to count 0



    The timer starts at 0, there are 249 increments until it hits 249, right? So, if you assume the timer goes straight back to zero after it matches, then it's not timing 1000 instruction cycles between matches, it's timing 996.
     
    Except it isn't - with PR = 249 it's actually timing a full 1000 instructions between matches.
    #7
    Chris A
    Super Member
    • Total Posts : 834
    • Reward points : 0
    • Joined: 2010/07/20 04:37:07
    • Location: 0
    • Status: offline
    Re: TMR2 2019/05/23 12:45:36 (permalink)
    +1 (1)
    Think of it this way.  The timer value remains at each of the 250 possible values for the same amount of time.  It doesn't suddenly jump when it gets to 249.
     
    Also note the interrupt does occur as the value becomes 249, not when it becomes 0.  That can be important to realise in some situations!
    #8
    ProfessorChaos
    New Member
    • Total Posts : 20
    • Reward points : 0
    • Joined: 2019/01/15 09:40:47
    • Location: 0
    • Status: offline
    Re: TMR2 2019/05/23 13:01:09 (permalink)
    0
    Chris A
    Think of it this way.  The timer value remains at each of the 250 possible values for the same amount of time.  It doesn't suddenly jump when it gets to 249.
     
    Also note the interrupt does occur as the value becomes 249, not when it becomes 0.  That can be important to realise in some situations!



    This is in fact what is happening. The responses above this all are making the assumption that the timer is reset to zero immediately on a match, but that's not what happens. (I think maybe the confusion is that the documentation implies/states that it does do that and also that the CCPx Compare/Special event trigger mode works like that.)
     
    The responses above in this thread seem like pretty good evidence that the documentation itself is misleading.
     
    Another bit of weirdness is that the very first period that you measure is one tick shorter than all the subsequent periods, which seems a bit odd if you think about it.
    post edited by ProfessorChaos - 2019/05/23 13:05:37
    #9
    ProfessorChaos
    New Member
    • Total Posts : 20
    • Reward points : 0
    • Joined: 2019/01/15 09:40:47
    • Location: 0
    • Status: offline
    Re: TMR2 2019/05/23 13:02:28 (permalink)
    0
    Belated apology for posting this in probably the wrong forum - I did look in hardware forums for similar topics and probably should have posted this there.
    #10
    qhb
    Superb Member
    • Total Posts : 9998
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: TMR2 2019/05/23 13:34:52 (permalink)
    +1 (1)
    ProfessorChaos
    Chris A
    Think of it this way.  The timer value remains at each of the 250 possible values for the same amount of time.  It doesn't suddenly jump when it gets to 249.
     
    Also note the interrupt does occur as the value becomes 249, not when it becomes 0.  That can be important to realise in some situations!

    This is in fact what is happening. The responses above this all are making the assumption that the timer is reset to zero immediately on a match, but that's not what happens. (I think maybe the confusion is that the documentation implies/states that it does do that and also that the CCPx Compare/Special event trigger mode works like that.)
     
    The responses above in this thread seem like pretty good evidence that the documentation itself is misleading.

    How do you make that conclusion?
    If it counts from 0 to 249, and spends the same amount of time at each count, then you have 250 counts, which is precisely what Chris A said. There's no requirement for a "sudden jump".
     
     

    Nearly there...
    #11
    ProfessorChaos
    New Member
    • Total Posts : 20
    • Reward points : 0
    • Joined: 2019/01/15 09:40:47
    • Location: 0
    • Status: offline
    Re: TMR2 2019/05/23 14:23:49 (permalink)
    0
    qhb
     
    How do you make that conclusion?
    If it counts from 0 to 249, and spends the same amount of time at each count, then you have 250 counts, which is precisely what Chris A said. There's no requirement for a "sudden jump".
     

     
    Technically, that not really right - it is 250 intervals when it counts from 249 to 249, not from 0 to 249. Like I mentioned above, unless you initialize the timer to 255, the first period is always going to be one tick short.
     
    Read the second, third, and fifth responses above - that's what I was referring to. They claim that the documentation says it jumps immediately back to zero after matching PR2 which is a) wrong and b) at a minimum. implied by the documentation and c) how the CCPx Special Event Trigger Compare option works (I think).
     
    I looked again in the hardware forums and I did find some references to the formula for calculating PR2 to be along the lines of:
     
    PR2 + 1 = Clock_Frequency / Desired_Interval
    (putting aside the pre/post=scalars)
     
    so evidently some people have been down this path before.
     
    Anyway, case closed on this one, I guess.
     
     
    #12
    mbrowning
    Just a Member
    • Total Posts : 1460
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: online
    Re: TMR2 2019/05/23 16:33:04 (permalink)
    0
    It isn’t intervals you count. It’s states, and from 0 to 249 there are 250 states that the counter goes through and then the next state is back to 0 with an accompanying IF

    Oh well - there's always next year
    #13
    1and0
    Access is Denied
    • Total Posts : 9495
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: TMR2 2019/05/23 19:06:27 (permalink)
    +3 (3)
    ProfessorChaos
    Technically, that not really right - it is 250 intervals when it counts from 249 to 249, not from 0 to 249. Like I mentioned above, unless you initialize the timer to 255, the first period is always going to be one tick short.

    Wrong!  It is 250 when it counts from 0 to 0, not to 249.
     
    This is kindergarten material. When you count from 0 to 9 and then the one's digit overflows to 0 in ten, how many numbers, counts, intervals, or cycles did you count?
     
    Let's break it down:
     
      0 to 1 is 1
      1 to 2 is 2
      2 to 3 is 3
      ...
      248 to 249 is 249
      249 to 0 is 250
     
    so there are 250 cycles or counts.
     
    Here is what the datasheet stated,
    PIC datasheet
    The value of TMR2 is compared to that of the period register, PR2, on each clock cycle. When the two values match, the comparator generates a match signal as the timer output. This signal also resets the value of TMR2 to 00h on the next cycle ...

    It says the NEXT CYCLE!!!  Bonus: The word "cycle" here means the count in the TMR2 register, regardless of the prescaler and postscaler.
    #14
    1and0
    Access is Denied
    • Total Posts : 9495
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: TMR2 2019/05/23 23:38:38 (permalink)
    0
    Chris A
    Also note the interrupt does occur as the value becomes 249, not when it becomes 0.  That can be important to realise in some situations!

    I am not so sure about that.
     
    The postscaler counts the number of times that the TMR2 register matched the PR2 register. After the postscaler overflows, the TMR2IF interrupt flag bit is set to indicate the Timer2 overflow; that is, TMR2 rollovers from the value of PR2 to 0x00.
    #15
    Chris A
    Super Member
    • Total Posts : 834
    • Reward points : 0
    • Joined: 2010/07/20 04:37:07
    • Location: 0
    • Status: offline
    Re: TMR2 2019/05/24 04:19:10 (permalink)
    0
    1and0
    Chris A
    Also note the interrupt does occur as the value becomes 249, not when it becomes 0.  That can be important to realise in some situations!

    I am not so sure about that.

    Actually as this is 8 bit TMR2 I am now not sure I am correct.  I can't find the old post now but I think I tested this on a PIC24 and PIC18 16bit timer.  It was actually the overflow interrupt so that could well differ from the PR2 match. I was testing by reading the value in the interrupt and would always catch the 0xffff value at time of interrupt which was a surprise at the time and meant extending the timer in the interrupt requires some care! (The simple way is to just add 1 to its value after any reading)
     
    It would be interesting to test TMR2 to prove it.
    post edited by Chris A - 2019/05/24 05:27:16
    #16
    Jump to:
    © 2019 APG vNext Commercial Version 4.5