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.
Bookmarks