PIC18F67K40 DT_INTS that really work.

[Dave]

Csantex, You need to set up one of your HIGH priority interrupts with a port bit that gets set during its routine and cleared at the end of it. Then set up another port bit (different) for the LOW priority interrupt and set it on entry and clear it on exit. Then take a scope and look at both bits during operation and see if the LOW priority is interrupted by the high priority interrupt, it should be.....

[richard]

You need to set up one of your HIGH priority interrupts with a port bit that gets set during its routine and cleared at the end of it. Then set up another port bit (different) for the LOW priority interrupt and set it on entry and clear it on exit. Then take a scope and look at both bits during operation and see if the LOW priority is interrupted by the high priority interrupt, it should be.....

I would not bother , if you look at the INT_CREATE macro it only creates high priority interrupts

;---[Stay compatible with the 14-bit version]---------------------------------
INT_CREATE macro
INT_CREATE_H
endm
ENDASM

dave is correct , to use h and low priority interrupts you must use INT_CREATE_L and use
INCLUDE "C:\PBP\INCLUDES\ReEnterPBP-18LP.bas" ; Include if using Low Pr. PBP INTS

[csantex]

Csantex, You need to set up one of your HIGH priority interrupts with a port bit that gets set during its routine and cleared at the end of it. Then set up another port bit (different) for the LOW priority interrupt and set it on entry and clear it on exit. Then take a scope and look at both bits during operation and see if the LOW priority is interrupted by the high priority interrupt, it should be.....

Dave,

Ok so I did the experiment but I used two identical timers with identical settings and I ran them both using the same format I've been using and also using the format described in you post and the pbp manual. Each timer had a pauseus delay of different values.
The high prty timer had pauseus = 10 and the low had pauseus = 20. Using my format only delays the next interrupt from occurring so what I thought were low and high prty interrupts were actually not. Using the correct format as you posted allows the the high prty interrupt timer to extend the low prty timer time, as its being interrupted. Now when I set both pause to equal value and both are set to high prty, one goes right after the other as they are listed. Occasionally, two interrupts will occur before the other one happens. It didn't matter which one was listed first. It was basically a first come first serve type event and setting the bits high or low at the IPR didn't make a difference. Attached is a picture of the first come, first serve events on the scope.

I think I will keep using the same format I've been using and apparently, they have all been high prty all this time. This would explain why it hasn't shown up as a problem before, it's always been a race to see who gets handled first and I work will really slow events that can wait to be handled when they cross that finish line. I can see the importance of having the difference in priorities when something needs to be handled exactly when it needs to be. I apparently don't need them just yet.

This exercise very enlightening. Thanks for the insight.

I am curious as to why you did ask me to show you an example.

[tumbleweed]

Just fyi -

The default state for the IPRx register bits is '1', so all interrupts default to high-priority.

[csantex]

Just fyi -

The default state for the IPRx register bits is '1', so all interrupts default to high-priority.

I see that now.

[Dave]

Csantex, I just asked out of curiosity. I didn't see how you were selecting the LOW and HIGH priority interrupt vectors.