• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 1977 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/TM4C1294NCPDT: Timer Interrupt priority

Shyam Shankar
Prodigy 220 points
Part Number: TM4C1294NCPDT

Tool/software: TI-RTOS

Hi,
How do I change the Interrupt priority of my Timer Interrupt. In the datasheet it shows up as interrupt priority is programmable. But How do i do it??

  • 0
    Guru 13040 points
    Shyam,

    Any interrupt priority is easily determined by Tivaware's function:

    IntPrioritySet(INTERRUPT, PRIORITY);

    That being said, be aware that interrupt priorities are much of a "fine tuning" for your system, and they actually only apply when more than one interrupt has been triggered WHILE another interrupt service routing was running (or when the "almost-impossible" happens that two interrupts trigger at the very same 8ns system clock "instant").

    In other words, if one given interrupt started to be served, others will not jump in even if they have higher priority.

    So the best overall solution for what you may believe is an interrupt priority issue is to keep REALLY SHORT interrupt service routines, set control flags in there, and later complement the processing of whatever the ISR started on a main-thread function later on.

    When you move to RTOS, you will naturally see this when dealing with software interrupts.

    Regards

    Bruno
  • 0 in reply to Bruno Saraiva
    Prodigy 220 points
    Thanks for the reply. But what i meant was..say i have a timer interrupt and a switch that generates an interrupt.. how would i manage the interrupt priorities of these 2?? Which one would have greater priority ?? How would I change it??
  • 0 in reply to Shyam Shankar
    Guru 13040 points

    Shyam,

    I understood your question. Let me try to clarify a bit more the answer. Consider a system in which there are only TWO INTERRUPTS enabled: a timer and a GPIO (an external switch). Your program is "doing nothing", on the main while() loop.

    The ONLY situation in which you would have a possible interrupt priority need is if BOTH the TIMER and the GPIO triggers at THE SAME TIME (or more specifically, within the same 8ns system cycle). In THAT CASE, the interrupt with higher priority would be serviced first.

    But that's quite rare, agree?

    Now, let's say again that your program was on idle in the main loop, and you push the switch. Your code execution moves to the ISR (Interrupt Service Routine) that you assigned for the GPIO. While the code is inside that function, even if the TIMER triggers, there is no change on the execution flow - it will still finish the function for the GPIO, and only then it will go into the function for TIMER. Priorities WILL NOT change that.

    Next case: if your system has 3 interrupts enabled: the GPIO, the TIMER, and let's say a SYSTICK. And as an example, your code is running inside the SYSTICK routine (which will last maybe some 2us...). Now, there is a much bigger chance that both the TIMER AND the SWITCH interrupts happen during such "longer period", agree? In that case, right after the SYSTICK interrupt function finishes, the interrupt priorities will be evaluated, and whichever between TIMER and GPIO had the highest priority will be executed first.

    It is technically possible to enable interrupts while inside ISR's - but I WOULD NEVER recommend that - it will make your system crazy to manage.

    Again: make your ISR's very short. Just figure out what caused the interrupt, capture some sort of event status, and set some pos-processing flag. Then, inside you main loop, check for that flag, and do the rest of the processing outside the interrupt routine.

    Hope it makes more sense. Otherwise, it is time to look at the time slice diagrams used for explaining interrupts...

    Bruno