TM4C1294NCPDT: About GPIO interrupt priority

Keirs,

The direct answer is you simply need to use Tivaware's fucntion:
IntPrioritySet(uint32_t ui32Interrupt,uint8_t ui8Priority)

Actually, from my experience, it is quite "rare" that you'd need to get as deep as to determine interrupt priorities... Unless you have some long code section running for an extended period while the interrupt services are disabled - which is not a good idea.

If you'd like to elaborate more on your needs, maybe we can share some thoughts.

Bruno

Bruno Saraiva said:

Actually, from my experience, it is quite "rare" that you'd need to get as deep as to determine interrupt priorities

I've yet to do a system that required interrupts that didn't also require managing the priority. The only reason to use interrupts is if latency matters and if it matters you need to manage the priorities.

Robert

Hey Robert, it seems today your are riding on a different road than mine... This is the second subject we "disagree" on the same day, but your points are perfectly reasonable and correct. :)

I understand your comment about needing to manage interrupts. But it is indeed the case for most of our applications here - that the order in which interrupts are served does not matter, as long as they are not "forgotten". If I have interrupts on GPIO's, completed SPI readings, complete analog reading, and you still have enormous 50ms to deal with those events, it does not matter which one is served first.

Unfortunately I'm not creative enough today to come up with an easy to follow example, but take my word: for 90% of the interrupts here, it does not matter which one is serviced first... (I guess we have relaxed applications...)

Cheers!

Bruno Saraiva said:

I understand your comment about needing to manage interrupts. But it is indeed the case for most of our applications here - that the order in which interrupts are served does not matter, as long as they are not "forgotten". If I have interrupts on GPIO's, completed SPI readings, complete analog reading, and you still have enormous 50ms to deal with those events, it does not matter which one is served first.

Then why use interrupts at all? If latency is not important polling is more efficient.

That's not to say that you cannot use interrupts, just that they don't appear to be required.

Robert

Bruno Saraiva said:

it is indeed the case for most of our applications here - that the order in which interrupts are served does not matter

While that's "offered up" - missing is (any) justification for such claim.     ("not creative enough (today)" ... is not particularly compelling.)

Do you (really) want to, "Pass such advice onto others"  - who may encounter your post - and "adopt" its guidance?     I have "no doubts" that you fully believe what you've presented - yet as it  "strays far" from the   "normal/customary"  - does it not warrant (some) justification/creativity?     (to properly describe, "IF & WHEN" this "Bruno Method" (No priorities) is safe to be deployed!)    That's fair - is it not?

How do you positively  "know"  - that the "near" or simultaneous arrival of two (perhaps even three) interrupts - will not demand (or at least provide "benefit") when "interrupt priorities are proper" and "in play?"  

Is it not true that w/out "interrupt priorities being considered - and applied" - that  "all code is enabled to run & execute equally?"    Is it not likely that several functions share, "key functional dependencies" - and may "mis-perform"  - and/or perform poorly" - when "shared data" is "missed" or  "passed out of order?"     (note that you yourself described the use of "volatile" - in the attempt to combat such - in another of your posts today.) 

Might the fact that ALL modern MCU vendors include the ability to "Prioritize Interrupts" - suggest that such "attention to detail" is more often "needed" than not?

It is perhaps the, "unusual and/or unexpected arrival" of interrupts - which may surely justify, "Use of prioritization."     If your code is simple enough to "escape" such prioritization - then any "Use of Interrupts" adds complication - (seemingly w/out benefit) - and may be judged "suspect."

Quick thought Bruno, care to go through an RMA exercise on your interrupts? No need to disclose anything proprietary or to do anything difficult but it might prove interesting to both of us and maybe to others as well.

Robert

Robert,

The extent we go to RMA here is very informal... We basically measure the time/clock count of the functions (mostly the long or more frequent ones), keep an indication of time critical requirements, and see if something gets too close to being dangerous.

Honestly our CPU's are not being pushed anywhere near to their limit, and this home-made recipe has been working fine.

There is one new implementation being currently developed, which is a 3 axes IMU. In theory, this will need about 60% of the capacity of a TM4C129, and I expect that this project will require a more detailed study of constrains. This 60% figure was obtained by a model spreadsheet in which we include all the expected functions and know timings, but that's before dealing with their priorities.

As you heard before, our developments have included a lot of wheel reinvention, for the lack of formal embedded training over lots of years... It was not the easiest way back then, but it was what could be done - and in the end we have some sort of "unique way of doing things"....

Bruno

You might be able to get more with less and greater surety in the process. You can run into realtime failures even at very low load if you don't handle scheduling well. And if the failures are infrequent then they can show up as simply odd field glitches.

I'm not suggesting a re-write, just an educational exercise to see what it shows.

60% is getting up there, as a rule of thumb 80% is usually considered fully loaded.

Robert

If you have more than one interrupts and one of them servicing hardware commands, then you need to make sure that it is higher in priority. For example, if you are controlling a power converter and one interrupt is updating the duty ratio of the PWM generation and the other is sampling the feedback signals for control and other high level tasks, you certainly don't want your PWM to wait for slow tasks (say status communication over CAN) to finish before it gets its updated duty ratio. I'd want the PWM interrupt to have the highest priority.

"Can I change the  interrupt priority of GPIO?"

yes, as the core supports it.

"If yes, could you tell me how to do it?"

it will depend on your tool chain. I work under CMSIS and the following does it: "NVIC_SetPriority(Irq, priority)".

it works across all CM0/1/2/3/4/7 familities, TI's or otherwise.

Greetings Rohail,

May I note your  "most excellent example"  -  which clearly identifies such "justification" for "Interrupt Priorities."     And for your "first ever posting" ... BRAVO!

Note too - that in "ultra-demanding" situations - one may,  "Extend & Enhance" Interrupt Priority via,   "Promoting a specific interrupt to, "PRE-EMPTIVE Status."      Such will enable the temporary  "Halt of an interrupt in progress" - and instead insure the "most rapid" execution of this "more favored" (i.e. pre-empting) interrupt.

Such proves a (very) nice (and powerful) addition to one's,   "MCU Bag of Tricks..."