Elapsed Timer findings

[pedja089]

I'm not sure that I understand problem, but I'll try to explain...
For 16 bit timer
$FFFF Is value at timer overflows to 0 when incremented by 1. So that value doesn't have anything with clock.
It does with timer(16 or 8 bit)
So If you need interrupt every timer tick, you will preload timer with $FFFF.
For 8 bit timer, value is FF, and if you increment that by 1, result is 0 and overflow.
8 is number of instruction to stop timer, load bytes to timer, and start timer. so you take it into count, when preloading timer.
And that is true only when clock for timer is Fosc/4. If timer is clocked from Fosc, then it will be 32 ticks for timer, if you load in 8 instruction.
But if you clock timer from slow clock eg 31KHz or 32768Hz, and processor is clocked from HS osc, you can preload timer in les than one tick. So you can ignore that...
(20 / 4) this is timer clock. And that value will depend on clock speed, not $FFFF.

[Art]

I know the instruction time is 20/4 (assuming 20MHz clock).
So if the timer registers were larger it would count 5M timer ticks per second.

DT’s Elapsed timer works by subtracting whatever value (depending on the clock speed)
from the timer overflow value to achieve 100 interrupts (and 8 instruction timer reload) per second.
I understand the 8 instruction cycles are compensated for in the constant value that will be continually reloaded to the timer.

My position is that one doesn’t subtract the value from $FFFF, but from $0000 which is where the overflow interrupt occurs.

The way that I synced the 1Hz pulse generated by the Elapsed timer code to a GPS pulse per second output
is by connecting it to portb.0 interrupt, and only allowing the interrupt to reset the second once.
The port.0 interrupt does not look at the timer value, only resets ticks so only synchronised within 1/100th of a second.

It only takes a little over an hour for a Human to notice (looking at two flashing LEDs) for them to desynchronise.
If the constant value is incremented by one, I’m on the third hour watching it so far.
Initially I was using a crystal running the Elapsed timer, but now rubidium.

'in the ISR after time variables are incremented
‘so don’t look at this yet, execution hasn’t gone here
'
if INTCON.4 = 1 then		' check if portb.0 interrupt enabled
if INTCON.1 = 1	then		' check if portb.0 interrupt occurred
INTCON.4 = 0			' disable portb.0 interrupt
INTCON.1 = 0			' clear portb.0 interrupt flag
Ticks = 0			' reset current second to gps pulse
endif
endif
‘
‘since the timer ISR was called by port.0 interrupt,
‘and not by timer overflow, any value could be in the timer.
’The Ticks are reset to extend the length of the current second.
‘We are only synchronised to within 1/100th of a second now,
‘but that’s enough for this purpose.

‘
'at the start of main program
'
'
INTCON.4 = 0			' disable portb.0 interrupt
INTCON.1 = 0			' clear portb.0 interrupt flag
'
INCLUDE "ElapsedTimer.bas"
'
'reset, and start the timer, etc.
‘

‘
‘when the main program has run for some seconds
‘the qualify bit can be set with a button, or auto set after some seconds have passed
‘
if qualify = 1 then		' synchronise command was qualified
OPTION_REG.6 = 1		' interrupt on rising edge of portb.0
INTCON.1 = 0			' clear portb.0 interrupt flag
INTCON.4 = 1			' enable portb.0 interrupt
'
‘some audible verification the sync command was qualified
‘
ENDIF

[pedja089]

You are right...
But in some example 7 instruction clock are used to compensate for preload. So it is same as if you substract from 0- or $10000.
I always use 32768Hz crystal, so I didn't pay to much attention to this.

[Art]

How is it demonstrated to everyone? Not everyone has two standards.
Best I can think of is logic buffer a 10MHz crystal to drive the pic chip running DT timer,
run a 1Hz flashing LED with the timer,
and also fan out the 10MHz clock signal to a cascaded bunch of frequency dividers to achieve
an independent hardware pulse per second derived from the very same crystal.
Then accuracy of the crystal is then a non-issue, and the two LEDs stray away from each other relatively quickly,
when the constant value is incremented by one, they will remain as synchronised as they were in the first place.
It really doesn’t take long, but is there an easier way?

[Art]

The seven instruction example you don’t mean the possibility of skipping an instruction in the reload section?
That always ends up 8 instructions no matter what the result of the bit test.
It takes two instructions to skip one instruction that would otherwise have to be executed.

Mods, this might end up inappropriate for this thread, which was not meant for pointing out errors.
I will do what it takes, and when done, it maybe is appropriate to clean up this bit of the thread.
This is still I think the best tool PBP has going for it.

[pedja089]

I found where i saw 7 instructions...
In misterE Pic Multicalc, default is 7 instr for reload.
Check it out, and compare results. As far I can see, it uses $10000.

[Art]

If it’s discovered, I’m real surprised it hasn’t been noted somewhere,
because original values/calculations are still being used also.
It would be affecting commercial products out there I’ll bet.
If you assume 7 instruction cycles for reload, and use the correct overflow value, isn’t that still exactly the same problem?

Test is easy.. make 10,000 Hz hardware PWM, and 100Hz PWM with Elapsed timer on the same chip.
10,000Hz is the lowest even freq at 50% duty cycle without resolution error assuming 10 MHz clock.
So then it only takes one pic and two dividers running from the same crystal.
Then any old crystal of any value doesn’t matter... run the chip as fast as possible, until the LEDs run away from each other.