Elapsed Timer Demo

[Bob_W]

Cool piece of code. I noticed something trying to use it..... I'm using a 12F675 at 4 mhz. I noticed that the ticks were incrementing at 1/4 the rate they were supposed to. Upon fishing around I thought about the fact that there's a 1:1, 1:2, 1:4, and 1:8 prescaler on this part, as well as many others. Forcing the prescaler off makes it count correctly. Just curious.... what part did you use when you wrote this?


Update... Nevermind.... I had left piece of my code in place that messed with the prescaler.

[Darrel Taylor]

That's the closest thing to "Hey it works" that I've gotten after it being here almost 2 years.

Thanks Bob!

[Bob_W]

Ok.... "Hey it works" Really well, I might add! A couple questions..
In elapsed.bas you've got:
if Ticks = 100 then
Ticks = Ticks-100
Is there a reason you subtract 100 instead of zeroing Ticks?

The question arises from a little excursion I had because of of the results I got doing subtraction to detect and handle rollovers. I found out that the first section evaluates true because of the unsigned nature of the math. I wound up reversing the sections and verifying the result for the rollover test wasn't > 255. Is there a better way. Also, what's the instruction count offset between 0x10000 - ((clock_freq / 4) /100) It looks like it's 7.

tmr is 80 Ticks sample at beginning of 500 ms interval
Ticks is 20 Ticks value now....

(The forum removed all my indentation, so it looks wierd)


ms100 = ticks
IF ms100 - tmr >= 50 THEN
GOSUB lptoggle
ELSE
IF ms100 < tmr THEN
IF (ms100 + 100) - tmr >= 50 THEN
GOSUB lptoggle
END IF
END IF
END IF
RETURN

lptoggle:
Toggle 0
RETURN

[Darrel Taylor]

Is there a reason you subtract 100 instead of zeroing Ticks?

Not really. The original program used ON INTERRUPT, and there was a possibility that Ticks might be higher than 100 by the time it got around to calculating the time. But when I switched it over to ASM interrupts, it wasn't needed anymore. Just never changed it.

And for the ms100 routine, I can't figure out what you're trying to do there.

If tmr = 80 then (ms100 - tmr >= 50) will be True when ms100 is between 0-79. So the output will be toggled on every loop. Then for 80-99 the (ms100 < tmr) will never evaluate True since it's always >= 80.

Maybe if you explained what you're trying to do, we can come up with something that'll work.
<br>

[Bob_W]

Basically, I want to turn something on - like an LED (later it will actually be a 7 HP siren with a longer on and off time) for 500 ms. I go through all the decision process to decide it should be turned on. Then....

I save the current ticks value - tmr - # of ticks at start, which is 16 for this grab.

I turn on the port - for the test program, I'm just toggling an LED at 500 ms intervals.

I come out of the main program loop every pass to see if I have expired my timer. Get current ticks - ms100 - we'll say I get 65 for this grab.

Sooo... IF ms100 - tmr >= 50 THEN 65 - 16 = 49.... almost there..

Where you run into the problem is if you grab, say 80 for tmr.

For 500 ms to elapse, you'd have to roll over the 100 mark. So, if you try to do the test IF ms100 - tmr >= 50 THEN with tmr = 80, and ms100 = 10 it evaluates true because, under pic math 10 - 80 = 250, or 65391 if you look at all 16 bits. So I figured out that you have to test to see if ms100 (the current tick value) is less than tmr (the tick value when you started timing) and if so, add 100 to the ms100 before subtracting tmr to see if it's 50 or better elapsed.

Sure you do timing with pause, but you can't look at change of state while you wait for pause to expire. Your timing routine makes it possible watch inputs, and manipulate and time multiple outputs at the same time.

I used to run into this when doing timing in vbdos. Seconds was easy - if you wound up with a negative, just add 86400.

[Darrel Taylor]

Well, I was hoping for more of what the program needs to do, instead of why it doesn't work the way you have it. But if I make a few assumptions I guess we can go from there.

Assumption 1 - The only thing the elapsed timer will be used for, is timing the 500ms periods.

Assumption 2 - The on/off cycle times are the same. 500ms ON, 500ms OFF. And repeats continuously untill it's determined that it needs to stop.

I believe the key here is in Starting the Elapsed Timer at the beginning of the alarm cycle so that it always starts at 0. That way you don't have to subtract the starting Ticks count from the current Ticks count. Al you'll need to do is test if it's less than 50.

Something like this...

Clear

Include "Elapsed.pbp"

AlarmOUT VAR PORTB.0
AlarmON  VAR BIT

;----------------------------
MainLoop:
; Somewhere in here determine when to turn on/off alarm
; and Gosub to either StartAlarm or StopAlarm

    if AlarmON and (Ticks < 50) then
       HIGH AlarmOUT       ' Alarm ON  
    else
       LOW  ALARMOUT       ' Alarm OFF
    endif
Goto Mainloop

;----------------------------
StartAlarm:
    Gosub ResetTime    ' Reset Time to  0d-00:00:00.00    
    Gosub StartTimer   ' Start the Elapsed Timer
    AlarmON = 1
Return

;----------------------------
StopAlarm:
    Gosub StopTimer
    AlarmON = 0
Return

HTH
<br>

[Bob_W]

The 500 ms on, 500 ms off is just an LED for testing your code. The beauty of your timer routine is that you can time multiple things at the same time......

Example...
Siren is running in first of four blasts - timing the on and off interval... WHILE...

Timing to see it someone is holding down the stop button more than 2 seconds.... WHILE timing to see how long it's been since activation, so we refuse to activate again if it's been less than, say , 5 minutes, so if the tones are sent over the air again, we don't drive the neighbors nuts.... ETC..


And, that's just this project.


Thanks.....