1ms Elapsed Timer Demo with DT's Instant Interrupts

[Art]

Hi

I was looking through your version and come across this again, as is also in DT’s original code:

; -----------------  ADD TimerConst to TMR1H:TMR1L
ADD2_TIMER   macro
    CHK?RP  T1CON
    BCF     T1CON,TMR1ON           ;  1 InstCycle, Turn off timer
    MOVLW   LOW(TimerConst)        ;  1 InstCycle
    ADDWF   TMR1L,F                ;  1 InstCycle, Reload timer with correct value
    BTFSC   STATUS,C               ;  1 or 2 InstCycles
    INCF    TMR1H,F                ;  1 InstCycle
    MOVLW   HIGH(TimerConst)       ;  1 InstCycle
    ADDWF   TMR1H,F                ;  1 InstCycle
    endm

I am wondering about a few things like why this is here:

    BTFSC   STATUS,C               ;  1 or 2 InstCycles

Depending on the carry status after the add, we would still have 8 instructions, because if the skip takes
two instructions, it skipped a line that would have taken another instruction.

I don’t understand why it’s necessary. If the ISR is called on timer overflow, then even if it is not zero
by the time it’s reset, it should be a known value, and not have to be checked.

This somehow looks like it’s setup as if the ISR was called a variable time after the overflow interrupt which should never happen.
I think there is something I’m not seeing, and the code it so simple, there must be a reason, otherwise it’s easily fixed.

I’m seeing error when I use a 10MHz crystal to generate a 1Hz LED pulse, and get it roughly synced (visible to Human) with
the output of a GPS pulse per second signal. After an hour I can see a difference between the two blinking LEDs,
which for a Human to see, would probably take some ms difference.
There could be error in my code, but I doubt that as I have only interfaced with DT’s timer,
or I have a terrible crystal, or board layout (very likely because the crystal is mounted to a two pin header to make it removable,
or crystals just really are that bad.

[Art]

Ok, so if you had other interrupts enabled, some timer ticks may have occurred before this routine?
I have only used the Elapsed Timer, and done others manually.

I hope you don’t mind discussion in your thread Tabsoft..
if another thread is needed, that’s ok, but I’m thinking some discussion is needed.

Incidentally, and not so related to this because DT does it slightly different... It appears MC don’t run their own samples:

[Tabsoft]

Art,

Tying to respond to your PM, but your inbox is full....

[Art]

This is about an issue of my own. There would be different ways to implement in a program.
It probably should have been commented like this:

; -----------------  ADD TimerConst to TMR1H:TMR1L -------------------------
ADD2_TIMER   macro
     BCF     T1CON,TMR1ON, 0       ;  1 Turn off timer
     MOVLW   LOW(TimerConst)       ;  1
     ADDWF   TMR1L,F, 0            ;  1    
     BTFSC   STATUS,C              ;  1 if carry set / 2 if carry clear
     INCF    TMR1H,F, 0            ;  1 if carry set /0 if carry clear
     MOVLW   HIGH(TimerConst)      ;  1
     ADDWF   TMR1H,F, 0            ;  1
     endm

‘ always up to seven instructions here since stopping the timer
‘ one more instruction will be used to turn on the timer in the
‘ code that called this, and there’s the eight instructions

I need to reset the timer (not add to it) if the ISR was triggered by port interrupt,
It looks like I’ll need another conditional and more instructions to check if it was portb.0 interrupt,
copy the constant values to the timer rather than add to it if it was called due to portb.0 interrupt,
and then also change the constant value to accomodate the extra instructions.

Because currently if the code was not called due to timer overflow, it is unknown what is in the timer.
It could be called by port.0 interrupt when a 0xFFFB value is in the timer for all I know.

My question if this is all because the whole DT interrupt set that can be enabled for multiple interrupts
to allow those interrupts be serviced first like I suggested above.

[Tabsoft]

Art,

First of all, let me say that I "assume" you are using DT's Instant Interrupts in the context of this question.

That being said, I am highly confident that DT "Adds" the Timer1 Preload constant (TimerConst) to the value of the Timer1 Counter
to account for the instructions executed in his Instant Interrupts Processor.
DT's Instant Interrupt Processor handles many things, including as you state multiple interrupts, but it also checks for and handles
Register Context saving for you. All of this takes instruction cycles to perform, ~91 instructions.

Also, the PIC MCU's Timer Interrupt is not instantaneous.
There is Interrupt Latency to contend with as well, which a good explanation can be found here in Microchip's Tech Bulletin TB3100.
http://ww1.microchip.com/downloads/c...s/cn566554.pdf

While Timer1 is enabled, the Timer1 Counter increments for each instruction cycle even after an overflow of the counter occurs.
This is a good thing and is exploited by DT to keep track of all of the processing I mentioned above until the Instant Interrupt Processor vectors to the ISR and the "ADD2_TIMER" macro is called and the "BCF T1CON,TMR1ON" statement is executed which turns off Timer1.

By "adding" the TimerConst to the value of Timer1's Counter, the time-based interrupt period is maintained as consistently as possible.

Hopefully this helps.

Secondly, if you are using DT's Instant Interrupts, why wouldn't you use a different label to vector to, for the PORTB.0 Interrupt on Change?
Is there a reason you would put it all in a single ISR handler?
Instant Interrupts should allow you to define multiple sources each with its own Label to jump to when the interrupt occurs.

Just curious.

[Art]

Ok thanks for confirming, I figured as much.
Dt’s original timer, or a bastardised version of it, because I know for the project it will always be clocked at 10 MHz,
and I also know I will only ever be interested in 100 Hz interrupt form the timer. The portb.0 interrupt is simpler, and I’ve done that manually.

To answer your other question.. It’s still about synchronising the timer to a GPS PPS pulse, but I want to go better than simply resetting Ticks,
and load the timer correctly for that situation as well... So when the program decides to sync, it enables portb.0 int, resets the flag for portb.0 int,
and then the next rising edge interrupt should call the same timer where it is loaded and then the portb.0 interrupt turned straight back off
unless the program decides to do the sync again at some later time.

Dealing with the timer ISR.. it seems I could save myself some instruction counting, and deal with the timer value the same way the reload code does
by just making sure the next Tick will occur correct time, rather than dealing with the current portb.0 int Tick that called the ISR.

This is my first play.. not sure about it and haven’t thought about it too much.. it’s my first play in a compiler since I started talking to you.
I disable ext int just a little later when the time values are being incremented and timing isn’t as critical.
For this version the constant needs another 6 added to it.

For most of the time ext int is disabled it’s supposed to act as it normally would, but take a little longer to execute.

; -----------------  ADD TimerConst to TMR1H:TMR1L
ADD2_TIMER   macro
    CHK?RP  T1CON

     BCF     T1CON,TMR1ON       ; 1 Turn off timer
     MOVLW   LOW(TimerConst)    ; 1

     BTFSC   INTCON,INTE	; 1/2
     MOVWF   TMR1L		; 1/0

     BTFSS   INTCON,INTE	; 1/2
     ADDWF   TMR1L,F            ; 1/0

     BTFSC   STATUS,C           ; 1/2
     INCF    TMR1H,F            ; 1/0
     MOVLW   HIGH(TimerConst)   ; 1

     BTFSC   INTCON,INTE	; 1/2
     MOVWF   TMR1H    		; 1/0

     BTFSS   INTCON,INTE	; 1/2
     ADDWF   TMR1H,F            ; 1/0

     endm

[Tabsoft]

Two initial questions.

1. Are you using DT's Instant Interrupts to handle the Timer1 Interrupt?
2. Is the code snippet below used for both interrupt instances you mentioned?
A. Timer1 100Hz Interrupt
B. PORTB.0 Interrupt to re-synch