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


+ Reply to Thread
Results 1 to 11 of 11
  1. #1
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,416

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

    With this post I'd like to visually demonstrate what kind of latency and overhead to expect when using DT-Ints. I'd like to point out that I am i no way criticising DT-ints, they are wonderful to work with and I could not imagine PBP without them but when you need to interrupt at high speed they are not that great and I wanted to put some numbers on it.

    To measure this I wrote a very simple piece of code, all it does is toggle an output as fast as it can. Then a periodic timer interrupt was introduced and in the actual interrupt service routine a short pulse on another output was created. Here's what that looks like on a scope:

    Name:  Overhead test 1.png
Views: 506
Size:  32.3 KB

    The top (blue) trace shows the output normally toggling at a fast rate. The bottom (yellow) trace shows the pulse generated by the code in the interrupt service routine. If we zoom in a little bit we can put some cursors on the screen and measure the latency:

    Name:  Overhead test 2.png
Views: 473
Size:  38.9 KB

    As soon as the interrupt trips the main code stops executing (output stops toggling) but OUR code in the interrupt service routine (which is what generates the pulse on the yellow trace) doesn't start to exectute until around DT-Ints have had to time to store a copy of the system variables which in this case takes around 7us. This PIC is running at 64MHz which means the latency on entry is roughly 112 instruction cycles.

    As soon as the falling edge of the pulse occurs we're done in the ISR and DT-Ints now has to restore all the system variables, clearing the interrupt flag and so on which takes slightly longer than on entry, around 8us or 128 instruction cycles:

    Name:  Overhead test 3.png
Views: 520
Size:  38.4 KB

    So, even though we're only spending 5us in the actual interrupt service routine the main routine is suspended for almost 21us - at 64MHz clock frequency. Even if no code at all was actually executed in the ISR the save and restore process that DT-Ints needs to perform takes, at the very least, somewhere around 240 instruction cycles. Now, 240 instruction cycles at 64MHz is "only" 15us which may no seem like much but if you're trying to interrupt at, lets say 25kHz you only got 40us between each interrupt. Spending 15 of those traveling to and from the interrupt plus, lets say, 5us in the ISR makes the 64MHz PIC "feel" like a 32MHz PIC. Any software timed commands in the main code (like PAUSE, SERIN, PULSIN etc) will off by a factor of 2.

    The above tests were done on an 18F25K20 running at 64MHz, using PBP 3.0.8.0 with support for LONGs disabled. With LONGs enabled the 15us overhead increases to roughly 18us or around 290 instruction cycles.

    Here's the code I used:
    Code:
    DEFINE OSC 64
    DEFINE LOADER_USED 1            ' We're using a bootloader.
    
    INCLUDE "DT_INTS-18.bas"
    INCLUDE "ReEnterPBP-18.bas"
    
    ASM
    INT_LIST  macro    ; IntSource,        Label,  Type, ResetFlag?
            INT_Handler   TMR0_INT,  _TimezUp,   PBP,  yes
        endm
        INT_CREATE              ; Creates the interrupt processor
    ENDASM
    
    ANSEL = 0
    ANSELH = 0
    TRISB = %11111100           ' PortB.0 and PortB.1 are outputs.
    
    ' Configure TMR0 to roll over at a rate of 31250Hz (every 32us)
    T0CON=%11000010             ' TMR0 on, 8bit mode, 1:2 prescaler
    
    @ INT_ENABLE  TMR0_INT      ; Enable INT0 interrupts
    
    Main:
        LATB.1 = !LATB.1        ' Toggle PortB.1 as fast as we can
    Goto Main
    
    TimezUp:
        ' Create a short pulse on PortB.0
        LATB.0 = 1
        PAUSEUS 5
        LATB.0 = 0
    @ INT_RETURN
    /Henrik.
    Attached Images Attached Images  
    Last edited by HenrikOlsson; - 18th August 2016 at 20:42.

  2. #2


    Did you find this post helpful? Yes | No

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

    That's good info Henrik. Saving the PBP system vars takes a lot of time!

    Do you have the same measurement done with an ASM-type interrupt handler?

  3. #3
    Join Date
    Sep 2009
    Posts
    722


    Did you find this post helpful? Yes | No

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

    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.
    Last edited by pedja089; - 19th August 2016 at 00:03.

  4. #4
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,416


    Did you find this post helpful? Yes | No

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

    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.
    Last edited by HenrikOlsson; - 19th August 2016 at 22:23.

  5. #5
    Join Date
    Aug 2003
    Location
    Australia
    Posts
    983


    Did you find this post helpful? Yes | No

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

    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.

  6. #6
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,260


    Did you find this post helpful? Yes | No

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

    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

  7. #7
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,416


    Did you find this post helpful? Yes | No

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

    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.

  8. #8
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,260


    Did you find this post helpful? Yes | No

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

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

    Ioannis

  9. #9
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,260


    Did you find this post helpful? Yes | No

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

    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.

    Name:  Latency.JPG
Views: 352
Size:  46.3 KB

    The code I used is this:

    Code:
    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
    Last edited by Ioannis; - 28th August 2016 at 10:50.

  10. #10
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,416


    Did you find this post helpful? Yes | No

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

    It seems that comparing to 25K20, the 887 executes less instructions...? Is it possible?
    Apparently....
    First of all, as pedja pointed out, the number of instructions will vary slightly depending on what commands are being used by the actual code. DT-Ints saves many variables by default and some more if they're being defined. DT-Ints 14 seems to allocate 41 bytes for storing context (including W, STATUS, PCLATH and FSR) while DT-Ints 18 allocates 68 bytes.
    Out of the 68 bytes allocated 22 is never used if LONGs are NOT enabled. So if I'm not mistaken worst case for 14bit devices is 41 bytes and for 16bit devices (without LONGs) it's 46 bytes so yeah...I don't think there's anything wrong with your test.

    What surprised me a bit though is that the entry is slower than the exit, while on the 18F it's the other way around. Also, in order to be truly accurate you really need to count instructions in the listing since measuring it like this can cause it to differ a couple of instructions. But visualizing it like this is easier :-)

    /Henrik.

  11. #11
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,260


    Did you find this post helpful? Yes | No

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

    I tested and measured it many times and it was consistent exactly as you observed. Entry always takes longer.

    Ioannis

Similar Threads

  1. DT-Ints latency and other interrupt conciderations
    By HenrikOlsson in forum mel PIC BASIC Pro
    Replies: 58
    Last Post: - 12th March 2010, 18:27
  2. DT-INTs Interrupt handler question
    By circuitpro in forum mel PIC BASIC Pro
    Replies: 1
    Last Post: - 8th January 2010, 00:06
  3. Issue with Array causing PauseUS to have 16uS overhead
    By bcd in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 10th November 2007, 08:41
  4. USART and interrupt latency - not a problem
    By barkerben in forum mel PIC BASIC Pro
    Replies: 0
    Last Post: - 18th January 2005, 22:57
  5. Interrupt Latency - ASM vs. Basic
    By barkerben in forum General
    Replies: 5
    Last Post: - 1st January 2005, 21:09

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts