Elapsed Timer findings

[pedja089]

I was playing with DT_Analog, and random variable set to 0 when I call GetADC.
This was happen only with long variable enabled.
So quick look and here is what happened:

#IF  __LONG__
    DTadAccum    VAR LONG ; local - 32-bit sample accumulator
#ELSE
    DTadAccum    VAR WORD[2]     ; local - 32-bit sample accumulator
#ENDIF

If I use PBPL then assembler use this line
DTadAccum VAR LONG ; local - 32-bit sample accumulator
And that is fine... Just declaring LONG var.
But later in code when Darrel clears accumulator:

DTadAccum = 0 : DTadAccum[1] = 0     ; clear the accumulator

So where is located DTadAccum[1]?
- 4 bytes after DTadAccum, and where was located my variables that get cleared after calling GetADC? You guessed...

Solution:
Replace

DTadAccum = 0 : DTadAccum[1] = 0    ; clear the accumulator

with

#IF  __LONG__
     DTadAccum = 0  ; clear the accumulator
#ELSE
    DTadAccum = 0 : DTadAccum[1] = 0  ; clear the accumulator
#ENDIF

And that's all.

[Art]

Hi Guys,
First up, respect to Darrel, the more I look into the timer code, it’s more than I thought it was.
It’s quite some extra trouble to accommodate us.
I pm’ed Tabsoft, and was going to wait, but even in the last hour, some results have been uncanny.

I think now, the fact that this works is a problem:

$FFFF - (((20 / 4) * 10000) - 8) = $3CB7

No matter if you like the other math, this works.
What is the significance of the value $FFFF? Nothing.
So I think the code is correct but the constant value should be $3CB8 for 20MHz,
and similarly, all original constant values need to be incremented by one,
and the current error is cumulative, and depends on the crystal frequency you’re using.
If not, have you clocked the code with a standard, and compared against an equal standard for any extended period?

I am not able to demonstrate in DT’s code any problem, because I think it’s only a math problem.
Cheers, Art.

[Art]

ps. Don’t be worried to speak, if I’m right this is very important to me, and probably also others.
If I’m wrong I’m not afraid to admit so, but the best thing to do whether he’s here or not, is fix any problem.

[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?