1
\$\begingroup\$

I have one generic question regarding interrupts. My software has 2 interrupts,lets say interrupt_x (timer), interrupt_y(spi).

Both interrupt has its own ISR. Interrupt_x has higher priority than interrupt_y. What does assigning priorities actually means? Does it means that Interrupt_x and interrupt_y will actually interrupt the core when it is supposed to, but the corresponding ISR will only execute based on their priority? Or does it means interrupt_x will prevent interrupt_y to interrupt the core when both interrupts happen together, because interrupt_x has higher priority and because of that their ISR is executed accordingly? The CPU is RL78/G14

\$\endgroup\$
  • 1
    \$\begingroup\$ What is your hardware platform? Did you read the datasheet/manual for the processor? It should have a section explaining interrupt priorities on that specific processor. \$\endgroup\$ – user253751 Mar 17 '18 at 6:35
  • 2
    \$\begingroup\$ The idea behind interrupt priorities is generic but the exact implementation and behaviour depends upon the CPU architecture you have. Which CPU is it? (edit information into your question, not in comments please) \$\endgroup\$ – TonyM Mar 17 '18 at 8:59
  • \$\begingroup\$ @TonyM: I have edited this in my question. But could you please tell me your idea about interrupt priorities even though its generic. This question didn't arise for me because I faced any problem in the software. Just I thought about this, independent of controllers. \$\endgroup\$ – user180742 Mar 17 '18 at 10:25
3
\$\begingroup\$

A priority interrupt controller has certain basic functionality that virtually all of this type share (as noted, certain specifics vary by device).

An example of one type might be useful.

Let's say I have a priority controller with 3 levels, A, B and C and that the priority order is A highest, B next, C lowest and each has been assigned to a particular event (timers perhaps, maybe a pin state change)

What could conceivably happen is this:

Interrupt C occurs; as there is currently no other interrupt pending, the interrupt vector is taken.

Before the interrupt handler for C completes, interrupt A occurs; the interrupt handler for C is suspended and the interrupt vector for interrupt A is taken (because interrupt A has a higher priority).

Prior to the interrupt handler for A finishing, interrupt B occurs; the interrupt handler for interrupt A continues (because B has a lower priority) until it completes and execution returns to the interrupt C handler (because that is where the processor was when interrupt A occurred).

The interrupt vector is immediately taken for interrupt B (because it has a higher priority than interrupt C) and completes the handler.

Execution now returns to interrupt C handler which can now complete (assuming neither of the other two interrupts happen in that time).

This is but one type of controller architecture, but it might give you the flavour of what these things do.

\$\endgroup\$
  • \$\begingroup\$ Does this means that interrupts will occur when it is suppose to, but the Interrupt handler will be executed based on priority. In such case I believe, no interrupt can prevent another interrupt to occur and priority which is being assigned is actually being assigned to Interrupt handler. Is it? \$\endgroup\$ – user180742 Mar 17 '18 at 16:52
1
\$\begingroup\$

Talking in general:

  • Let there be 3 interrupts with different priority levels. And all are enabled by interrupt enable registers, so that the system is ready for interrupts. Interrupts are just signals coming from external circuit and hence can occur at any time. ISR is the task that should be performed by the controller when an interrupt occurs. Whenever an interrupt occurs, corresponding interrupt flag is set. And the corresponding ISR is executed. Finally, the flag is cleared at the end of ISR to accept further interrupts of the same kind.
  • If all 3 occurred at same time, their ISRs will be executed in the order of their priorities.
  • Suppose they occur at different times. Say the highest priority ISR is being executed now. It is not going to be affected even if the rest two lower priority interrupts occurred in between, together or at different times. But they have set their flags and hence we can say they are in "pending" mode. They will be executed as per their priorities, once our highest priority ISR is finished.
  • Suppose a lower priority ISR is being executed. If a higher priority interrupt occurred in between, lower priority ISR "pauses" and the higher priority ISR will start execution. After it is finished, the lower priority ISR can "resume" from wherever it "paused".
  • In summary, higher priority interrupt can "interrupt" the execution of lower priority ISR any time (known as preemption in nested interrupts), while lower priority cannot preempt higher priority ISR. It can only wait or remain "pending". However, whether nested interrupt is supported, their priorities, levels of nesting, all are architecture dependent. Hence should go through datasheet.
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.