What's the interrupt latency and/or overhead when using DT-Ints?

[pedja089]

As far as I know, if you have more than one INT_Handler, then it will take more time to do overhead checking on what label to jump, even if only one interrupt occurred. And further down the list it will take more time to jump to that label.
ASM int header is faster "only" for save and restore time needed. Which is not small at all.
From Re-EnterPBP-18 file, we can see that it need maximum 34 word to be saved and restored(can be less, depending on conditional assembling). Variables are grouped, so only one banksel instruction are needed.
To save or restore 34 words(68 bytes) we need 136 instructions(one to load to W and one to load to F). I didn't check if PBP uses MOVFF, so maybe there is room for improvement.
So worst case: just to save and restore PBP variables takes 280 instructions(272 movX instructions, +2 call, +2 returns, +2 banksel)
Henrik's test program didn't have any IF then so didn't have any of T variables used, that is why it was faster.

[HenrikOlsson]

I was going to say that the actual overhead can and will be different depending on what commands your program is using but compared to what's already there we're not talking about much. If it's really critical then my suggestion is to either measure it yourself or use the worst case number, which Pedja says is 280 instructions when not using LONGs.

As for declaring the interrupt type as ASM while still using DT-ints the total (measured) overhead is around 7.6us - a difference of 8us or 128 instruction cycles. But if you're going to write the interrupt handler in assembly then you don't really need DT-Ints anyway and the overhead will become very small.

Finally, the measurement shown here are all approximate, counting instruction cycles is Always a more accurate way, this was juse meant to visually show what's going on and put some sort of number on it for people who may be wondering.

/Henrik.

[Art]

Nice Mostly, knowing the time you lost is important, rather than the fact you lost the instruction time itself,
and all you really need to do is measure it. I think everyone should trim down anything like that.
If you were only using DT Elapsed timer, and needed the second tick without counting Hours, Mins, Secs,
you might as well remove the checks and get the instruction time back as any given project develops.

[Ioannis]

Nice job Henrik.

It would be very interesting to see the timing on a modest PIC like F886 or similar. Will try this when in lab.

Ioannis

[HenrikOlsson]

Please do and post the results.
It's going to be slightly worse on an old 14bit device since they don't have automatic context save/restore like the 18F devices do for high priority interrupts.

/Henrik.

[Ioannis]

Exactly because of that I am sure it will be much worse. Soon...

Ioannis

[Ioannis]

Finally I did the test on a 16F887 at 8MHz, and came up with a 49 usec to enter ISR and around 45 to exit.



The code I used is this:

wsave   var byte $70 system
wsave1   var byte $A0 system
wsave2   var byte $120 system
wsave3   var byte $1A0 system


INCLUDE "DT_INTS-14.bas"
INCLUDE "ReEnterPBP.bas"

ASM
INT_LIST  macro    ; IntSource,        Label,  Type, ResetFlag?
        INT_Handler   TMR0_INT,  _TimezUp,   PBP,  yes
    endm
    INT_CREATE              ; Creates the interrupt processor
ENDASM

TRISB = %00000000           ' PortB.0 and PortB.1 are outputs.

@ INT_ENABLE  TMR0_INT      ; Enable INT0 interrupts

Main:
    portB.4 = !portb.4        ' Toggle PortB.1 as fast as we can
Goto Main

TimezUp:
    ' Create a short pulse on PortB.0
    portb.5 = 1
    PAUSEUS 15
    portB.5 = 0
@ INT_RETURN

It seems that comparing to 25K20, the 887 executes less instructions...? Is it possible?

Ioannis