Elapsed timer not working as expected at 64MHz

[longpole001]

yep there was no elapsed-18_k22

[richard]

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

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

[Demon]

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

[richard]

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

[Demon]

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.

Oh and I don't like fish.

Robert

[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

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

[Demon]

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

[Art]

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.

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

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

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

Now if you have to display the seconds anywhere just:

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:

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.

[Demon]

...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