Elapsed timer not working as expected at 64MHz

also robert if your using the 18FxxK22 range of pics and DT ' ints you better to use his modified version of the specifically for the 18Fxxk22 range - as it allows for the changes in how the registers are used / accessed for some the supported functions in the k22 range , microchip changed how they are named / accessed from what i remember

Quote:

---

Originally Posted by longpole001

ticks should be 2.5ms , 1/100 is 4 x tick = 10ms , 1 sec should be 100 x 1/100th or 400 tick = 1sec

---

From my observations so far:

I think this is the core of the problem. With older PICs (I'm thinking up to 40MHz), a tick of 1/100 of a second was the smallest unit Darrel was able to attain. Now with newer PICs reaching 64MHz, a tick was now 4 times smaller. I can only guess that the old way of doing things in the background by Microchip was based on 16MHz processing, that would explain ticks becoming 4 times faster when using 64MHz.

As I mentionned in the chatbox last night, this is a PIC-specific issue. Sheldon mentionned that Darrel has released a 18FxxK22 version of the Elapsed Timer. I totally missed the release of this include. There's no mention of it in the archived web pages of Darrel's work (not surprising - they are old).

So I'll remove my modified version and leave people use Darrel's new version instead.

Robert

No need to remove it - there's nothing wrong with having more than one program that does the same thing!

The problem with multiple versions is maintenance. If a problem is found in one version, it must also be corrected in the other - duplicating work. For example, when Microchip decides to change how things work in the background.


Right now I can't seem to find a post where Darrel released his Elapsed Timer for 18FxxK22 PICs. Has anyone else seen it?

Or was it possibly distributed through PM?

Robert

hi robbert
it was not released specifically for the elapsed timer , as that code uses timer 1 ,
and both versions must be maintained as the K22 version is specific to the registers that have changed for the K22 series

the ints-18_K22 version was on His site from memory


The modified version is used specifically on the 18fxxK22 ,for the following reasons

1. TMR4 - changed from PIR3 to PIR5 in K22 ver
2. TMR5 and TMR6 support added to support the addtional timers in the K22 series
3. ccp3 , ccp4,ccp5 - changed PIR3 to PIR4 in the K22 range


this is confirmed when comparing DT_INTS-18 AND dt_INTS-18_K22 of the code

the addtional / changed code in K22 version is as follows


regards

Sheldon

Code:

---

  #define TMR4_INT  PIR5, TMR4IF    ;-- TMR4 to PR4 Match
#define TMR5_INT  PIR5, TMR5IF    ;-- TMR5 Overflow
  #define TMR6_INT  PIR5, TMR6IF    ;-- TMR6 to PR6 Match

---

ccp3- ccp5 , uses PIR4 in the K22 , where other f18 use PIR3

Code:

---

#define CCP3_INT  PIR4, CCP3IF    ;-- CCP3
  #define CCP4_INT  PIR4, CCP4IF    ;-- CCP4
  #define CCP5_INT  PIR4, CCP5IF    ;-- CCP5

---

further support for the changed TMR4 and extra timers 5 and 6 in k22 range

Code:

---

ifdef TMR4IF  ;----{ TMR4 Overflow Interrupt }------------[PIR5, TMR4IF]---
      INT_Source  PIR5,TMR4IF, PIE5,TMR4IE, IPR5,TMR4IP
  endif

 ifdef TMR5IF  ;----{ TMR5 Overflow Interrupt }------------[PIR5, TMR5IF]---
      INT_Source  PIR5,TMR5IF, PIE5,TMR5IE, IPR5,TMR5IP
  endif
  ifdef TMR6IF  ;----{ TMR6 Overflow Interrupt }------------[PIR5, TMR6IF]---
      INT_Source  PIR5,TMR6IF, PIE5,TMR6IE, IPR5,TMR6IP
  endif

---

again further support of the changed interupt register from normal 18f pics ( PIR3) to that of the K22 (PIR4) for the CCP3-5

Code:

---

  ifdef CCP3IF  ;----{ CCP3 Interrupt Flag }----------------[PIR4, CCP3IF]---
      INT_Source  PIR4,CCP3IF, PIE4,CCP3IE, IPR4,CCP3IP
  endif
  ifdef CCP4IF  ;----{ CCP4 Interrupt Flag }----------------[PIR4, CCP4IF]---
      INT_Source  PIR4,CCP4IF, PIE4,CCP4IE, IPR4,CCP4IP
  endif
  ifdef CCP5IF  ;----{ CCP5 Interrupt Flag }----------------[PIR4, CCP5IF]---
      INT_Source  PIR4,CCP5IF, PIE4,CCP5IE, IPR4,CCP5IP
  endif

---

Quote:

---

...this is confirmed when comparing DT_INTS-18 AND dt_INTS-18_K22 of the code...

---

Ok, so the K22 version is for the main DT_INTS-18 include, not the DT_Elapsed-18 include. I hadn't understood that.

Robert

yep there was no elapsed-18_k22

seems to me the easiest way to restore correct function for "ticks" when the post scaler is in use is to move the ticks loop inside the post scale loop , no extra vars no extra overhead

Code:

---

ClockCount:
@ RELOAD_TIMER                  ; Reload TIMER1

    T1Post = T1Post + 1
    IF T1Post = T1PS THEN
      T1Post = 0
    Ticks = Ticks + 1
        IF Ticks = 100 THEN
          Ticks = 0
          Seconds = Seconds + 1
          SecondsChanged = 1
          IF Seconds = 60 THEN
              Seconds = 0
              Minutes = Minutes + 1
              MinutesChanged = 1
          ENDIF
          IF Minutes = 60 THEN
              Minutes = 0
              Hours = Hours + 1
              HoursChanged = 1
          ENDIF
          IF Hours = 24 THEN
              Days = Days + 1
              DaysChanged = 1
              Hours = 0
          ENDIF
      ENDIF
    ENDIF
@ INT_RETURN                    ; Restore context and return from interrupt

---

I can only think that there was a reason why Darrel did it as he did. The dude could probably code this stuff while playing ping pong; the Bruce Lee of PBP and ASM.

There's more than one way to solve a problem, he probably took the one that worked for all PICs (until the K22 series came along). And even that he's solved the problem, it just wasn't widely known. I can only think he had greater concerns on his mind. Can you imagine how much of a headache it must have been tracking the new releases versus his routines? Makes me appreciate and miss him even more.

I now fear the day when Microchip releases a new product line. I love the K22 like I loved the 16F628 and 16F877, I'm not changing unless I'm forced to change.

Shoot, I might even stay on PBP 2.6. LOL

it has nothing to do with the k22's its the problem exists whenever the T1PS value is >1 on any chip
its all to do with the way he implemented the post scaling , the loops are inside out . its no bigie to fix . its only apparent if you need to use "ticks" .
imho most of the time using ticks is pointless by the time you process the reading and then display it it's already meaningless and out of date . if you want to time events to such accuracy trigger times need to be allowed for and properly sync'ed , there are much better ways
ps
the k22 interrupt vagaries are a separate issue and unrelated to ticks not being 100th's of a sec

Quote:

---

its only apparent if you understand what's going on .

---

There, fixed it for you. LOL

I never dealt with timer guts before. I always thought pre-scaling and post-scaling were what the fish looked like when my mom prepared them. :D

Oh and I don't like fish.

Robert

you have to toggle your led at the correct place in the loop
the interrupt runs at 4x the speed required (because of high fosc not chip type ) for timing so the post scaler divides it by 4

Quote:

---

ClockCount:
@ RELOAD_TIMER ; Reload TIMER1

T1Post = T1Post + 1
Robert toggle your pin here eg latd.0=!latd.0 for 2.5mS
IF T1Post = T1PS THEN
T1Post = 0
Ticks = Ticks + 1
Robert toggle your pin here eg latd.1=!latd.1 for 10mS
IF Ticks = 100 THEN
Ticks = 0
Seconds = Seconds + 1
SecondsChanged = 1
IF Seconds = 60 THEN
Seconds = 0
Minutes = Minutes + 1
MinutesChanged = 1
ENDIF
IF Minutes = 60 THEN
Minutes = 0
Hours = Hours + 1
HoursChanged = 1
ENDIF
IF Hours = 24 THEN
Days = Days + 1
DaysChanged = 1
Hours = 0
ENDIF
ENDIF
ENDIF
@ INT_RETURN ; Restore context and return from interrupt

---

Quote:

---

Originally Posted by richard

...imho most of the time using ticks is pointless by the time you process the reading and then display it it's already meaningless and out of date . if you want to time events to such accuracy trigger times need to be allowed for and properly sync'ed , there are much better ways
ps
the k22 interrupt vagaries are a separate issue and unrelated to ticks not being 100th's of a sec

---

I disagree. This is the first time I have a specialized need for a timer and it requires knowing how long a tick really is. I want to debounce using interrupts, so I press a button, look how long it takes for the contact to close and open again, take an arbitrary average and add maybe 25%, that's my debounce in mSeconds.

I know others use timers in what I consider a more complicated way, I have no clue how a preload value works and can never remember if the timer counts up or down from there (I have a hard time remembering little details like that). To them it's easier, I prefer the elapsed timer approach.

I turn a LED on and off, check the interval on the Saleae probe (I should get a commission every time I typed that), and that's it. Ticks=10mS is stuck in my brain ever since I first saw it on Darrel's include. I just count the ticks until I get my interval.

When you think about it, if we were that concerned with accuracy, we'd program in assembler.

Robert
:)

Quote:

---

Originally Posted by richard

you have to toggle your led at the correct place in the loop
the interrupt runs at 4x the speed required (because of high fosc not chip type ) for timing so the post scaler divides it by 4

---

I know that now because I've spent 3 days on this. LOL

But ask me in a week and I won't remember, I'll spend another day running around my tail wondering why I get 4 times too many ticks at 64MHz.

I might eventually remember this long-term, if I do it for weeks. But I have sleep apnea that can't be treated completely, so what I experience during the day doesn't always get stored properly overnight in my sleep. Consider me as obsessive compulsive against my will. I can leave comments about quadruple ticking, but I'll glance over the comment and ignore it until it bites my face for a day or so. LOL

Shoot, my wife gave me $600 a month ago and I totally forgot.

Robert

Hi Robert,
Getting to know the timer is fine, but that would be otherwise extreme for button debounce.
You can do a program timer to lock the button for a delay after being pushed.

Code:

---


dtimer var byte
dtimer = 0

main:

IF port.1 = 1 && dtimer = 0 then
dtimer = 200
gosub fire ‘oh no, he pushed the button, all hell is going to break loose.
endif


IF dtimer > 0 then
dtimer = dtimer-1
endif

goto main

---

If you needed interrupt driven buttons it would pay to set the timer in the ISR and
decrement the timer in your main program, and reenable interrupts when the timer reaches zero.

It’s good practice to keep interrupts for the thing that really needs it… like keeping real time is a good example :D

With regard to the speed, you can’t count to 400 in your Ticks byte,
but you can count to 240 Seconds (instead of 60 Seconds) to delay the time

Code:

---

          IF Seconds = 240 THEN
              Seconds = 0
              Minutes = Minutes + 1
              MinutesChanged = 1
          ENDIF

---

Now if you have to display the seconds anywhere just:

Code:

---

DisplaySeconds var byte

DisplaySeconds = Seconds / 4 ‘ divide by four
‘print Hours, Minutes, DisplaySeconds.

---

If you needed a high speed signal find and asm routine to rotate a byte with carry, and output bit.0 out a pin.
The benefit of that is ensuring it takes a constant period of time to run the check.
You might find in this code:

Code:

---


IF flag = 0 then
flag = 1
else
flag = 0
endif

---

once it’s decompiled it could take a cycle less to execute depending on the result.
So if you’re trying to produce a square wave it could be jagged.
These things are easier to do with HPWM of you have the hardware though.

With the thing running exactly 4 times too fast I would have rotated this byte (with carry),
and read the value of bit0 each time:

Code:

---

%00001111

---