+ Reply to Thread
Results 1 to 8 of 8
  1. #1
    Join Date
    Jun 2017
    Posts
    39

    Post DT_ints handling time.

    Hello to everyone.

    My question is: Does anyone know the minimum time it takes for the interrupt handler (DT_Ints) to kick in and start processing the interrupt? I currently have one interrupt on change actively waiting for a port pin to change. I want to know if anyone knows how long it takes for the interrupt handler to react/respond to the port pin change. The particular device I'm using is the 18F67K40. Its data sheet states the a minimum of 50nS after changing states, is needed at a logic 1 or 0 in order for the IOC to be valid. Does anyone know how long after that, it takes for DT_ints to start processing the interrupt.

    My current setup:
    Using high priority interrups.
    PortG.5 is set to generate an interrupt on a positive going edge.
    I set PortG.3 to logic 1 to indicate that I have entered the interrupt.

    I use this setup to time the interrupt from when it's being generated and when I respond to it.
    The current time is 9.5 microSeconds. It may not be a long time but i need it to be faster than that.

    All feedback is appreciated.

  2. #2
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,258

    Default Re: DT_ints handling time.

    It depends on a couple of things. The device family (18 series in your case), if LONGs are being used, if your program has resulted in PBP using any of its T-variables, if you're using a PBP handler or an ASM handler - and obviously at what speed you're running the chip.

    The thing with DT-ints, which is how it allows us to us PBP in the interrupt handler is that it stores (on entry) and restores (on exit) all the variables that PBP uses internally. Saving/restoring those variables takes time and there simply is no way around that.

    For best performance a pure ASM interrupt is needed. Then comes DT-Ints using an ASM handler. Then (and I don't recommend this if you don't know what you're doing) using a PBP handler which you examine to determine exactly what variables needs saving/restoring and "manually" handle that on entry/exit. And finally, the easiest but slowest, using DT-Ints with PBP type handler.

    And, the question you should ask yourself is not what the minimum time is but rather what the MAXIMUM time is - and if that is acceptable or not for your application.

    /Henrik.

  3. #3
    Join Date
    Jun 2017
    Posts
    39

    Default Re: DT_ints handling time.

    Thanks for your feedback Henrik.

    I'm currently running this Pic at 64mhz. No Longs are being used so that's not an issue here I would think. I have multiple interrupts being handled thru DT_Ints that I would really prefer not to have to rewrite them in assembly. I disabled all of those interrupts and wrote the IOC interrupt in assembly for the sake of this test which only saved me 1.5 to 2 microSeconds. I still used DT_Ints to handle it. I looking for less time to respond but it wasn't as much as I was expecting. I think that will as good as it gets.

    Thanks again for the feedback. I will look for a different way if possible.

    csantex

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

    Default Re: DT_ints handling time.

    Hi,
    OK, the simple band-aid would be to up the frequency but since you're running at 64MHz already that won't work. You said you re-wrote one of the handler in ASM but did you also change the declaration within DT-Ints from PBP to ASM?
    With DT-Ints and ASM interrupts there's still a little bit of overhead (but no THAT much). I seem to remember measuring that at some point and that I gained more than a 2us.

    Anyway, if you really want to keep the handlers as PBP code then the only thing you can do is to (very) carefully examine the compiled code of the handlers (and all the library calls they may make), make a list of which PBP variables are being used and then save/restore those yourself. This is what DT-Ints does but it's not clever enough to figure out which variables are actually "touched" by the code in the ISR so it saves them all. I've done this occasionally but it's error prone and breaks easily if/when you change the ISR. If you, unlike me, are good at ASM it's probably better to re-write the handlers in ASM.

    If you haven't already seen it there's a thread discussing the overhead and latency when using DT-ints here: http://www.picbasic.co.uk/forum/show...T-Ints+latency

    Here's another thread form 10 years ago with some useful information on the subject: http://www.picbasic.co.uk/forum/show...T-Ints+latency


    /Henrik.

  5. #5
    Join Date
    May 2004
    Location
    NW France
    Posts
    3,541

    Default Re: DT_ints handling time.

    Could that Help ???

    Alain
    ************************************************** ***********************
    Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
    ************************************************** ***********************
    IF there is the word "Problem" in your question ...
    certainly the answer is " RTFM " or " RTFDataSheet " !!!
    *****************************************

  6. #6
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,258

    Default Re: DT_ints handling time.

    No, I don't think it could.
    It will tell you the size of the code (ie how much FLASH it occupies). It doesn't tell you anything about which system variables the code uses.

    /Henrik.

  7. #7
    Join Date
    May 2004
    Location
    NW France
    Posts
    3,541

    Default Re: DT_ints handling time.

    so ...

    size of code could be a good help to calculate the duration ... with little effort.

    MPLAB 8.92 simulator should also do it ...

    I sometimes have trimmed the timing with it ...

    BTW ... 9.5 µs looks to me to be ASM treated ... especially if you have a bunch of PBP variables ...

    One step further ...

    you could have a close look to the generated desassembly listing ... ( see attached )

    you could see there is some room just @ the interrupt " jump" location ( so, BEFORE any interrupt stubb ) and simply place some ASM " bsf portG.3 " instead of one of the " nop " s past the jump location ...
    you also can re-place the
    GOTO INT_ENTRY_H
    from address 4 to 12 ...

    and then, just program your chip with that ASM modified source. Note that won't look at the interrupt origin ... just High or Low level ...

    that not exactly " full PBP " but a nice trick ... isn't it ???


    Alain
    Last edited by Acetronics2; - 24th April 2019 at 13:25.
    ************************************************** ***********************
    Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
    ************************************************** ***********************
    IF there is the word "Problem" in your question ...
    certainly the answer is " RTFM " or " RTFDataSheet " !!!
    *****************************************

  8. #8

    Default Re: DT_ints handling time.

    The fastest you can respond to a high-priority interrupt is 5-6 instruction cycles (assuming there's a GOTO at the vector location), so at 64MHz that's 375ns before your ISR code begins to execute.

    If there is only a single high-priority interrupt source then there's no other testing that needs to happen...
    you know what the interrupt source is so you can begin handling the interrupt at that point.
    If you're concerned with speed then make all other interrupt sources low-priority.

    Whether you have to save additional registers/variables depends on exactly WHAT the ISR needs to do, which you haven't specified. I'd start with that. Once you know what the ISR does then you can figure out how to make that happen.

    Unless all you want to do is set a bit high or low I wouldn't try mucking around with shoving code into those vector locations... there's just not enough space to do much and it can get you into trouble later.

Similar Threads

  1. GLCD handling in PBP
    By spreader in forum mel PIC BASIC Pro
    Replies: 3
    Last Post: - 17th March 2009, 23:58
  2. 16F872 and interrupt handling
    By Robson in forum mel PIC BASIC Pro
    Replies: 10
    Last Post: - 6th July 2007, 05:12
  3. handling Large Numbers
    By Peter1960 in forum mel PIC BASIC Pro
    Replies: 12
    Last Post: - 26th April 2007, 02:33
  4. Handling Serial 8N2
    By bcd in forum mel PIC BASIC Pro
    Replies: 4
    Last Post: - 30th July 2006, 14:45
  5. Improved interrupt handling
    By Desterline in forum PBP Wish List
    Replies: 2
    Last Post: - 10th November 2003, 15:56

Members who have read this thread : 25

You do not have permission to view the list of names.

Posting Permissions

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