3
\$\begingroup\$

In RTOS, when a Higher Priority task becomes Ready to Run, it stops or preempts currently running (Lower Priority) task and start executing itself. Before switching tasks, RTOS saves required data related to lower priority task (Context Switching)

Coming to my question, Like tasks, Interrupts also have priorities. When a Lower priority interrupt is executing and a Higher priority interrupt comes, What happens? Does it stores all data on Stack etc. just like RTOS? What will happen to my variables used in ISR?

(Note that, this scenario is possible in a Non-RTOS based application too!)

\$\endgroup\$
4
  • \$\begingroup\$ Depending on the platform you can also have recursive interrupts of the same priority and even a specific interrupt interrupting itself (for example an external interrupt called while an external interrupt is already being executed ) \$\endgroup\$
    – alexan_e
    Commented Jan 29, 2014 at 10:18
  • \$\begingroup\$ This depends very much on the processor. The processor doesn't know what data is important so cant store it all anywhere. This does not matter however as your data is stored in memory either on the stack or elsewhere so wont change. What does matter is what's in the registers some processors have a separate bank of registers for interrupts others will push a limited set on to the stack. If you want to use any other register you will need to remember to push it on to the stack before you change it then pop it back off before you return from the interrupt so all registers are unchanged. \$\endgroup\$ Commented Jan 29, 2014 at 10:20
  • \$\begingroup\$ @WarrenHill What I want to ask is, Does processor take any actions similar to Context Switching, Not only stack but anywhere and according to you, it does that! But I didn't get your next statement. Why would I change a register if I know next operation will restore previous value in it OR why will I restore previous value in Register if I just changed it? \$\endgroup\$
    – Swanand
    Commented Jan 29, 2014 at 10:25
  • \$\begingroup\$ When an ISR occurs the value in any register may need to return to its original value before returning from the interrupt as the code that was interrupted may be using it. Now your ISR will need to use registers to do what it needs to do and you may need more of them than are stored automatically as part of the interrupt. If you do then you need to save it first then you can use it for what you want but when you have finished with it change it back so the original code still has the correct value. Most people use the stack for this but it could be somewhere else. \$\endgroup\$ Commented Jan 29, 2014 at 10:32

2 Answers 2

4
\$\begingroup\$

This is basically entirely platform and compiler dependent. Some MCUs/CPUs have hardware for saving some or part of the stack, some do not.

Additionally, Stack saving/loading is compiler-determined on some platforms. At least on atmel's xmega MCUs, context saving is up to the code, rather then the hardware. You can therefore write naked ISRs that could muck with the previous context without too much trouble.


Basically, there is no general rule aside from "read the docs of the CPU in question".

\$\endgroup\$
3
  • \$\begingroup\$ To Summerize, Controller doesn't do anything. It all depends on Programmer/Compiler... But there are some "smart" controllers who are capable of taking care of this!! \$\endgroup\$
    – Swanand
    Commented Jan 30, 2014 at 3:52
  • 1
    \$\begingroup\$ @Swanand - It's completely possible for a CPU to have hardware context saving for interrupts. There is no general rule aside from reading the documentation. \$\endgroup\$ Commented Jan 30, 2014 at 4:57
  • \$\begingroup\$ If you include the possibilities of what you can do in soft-core CPUs (such as the kind implemented in FPGAs), literally every interrupt topology is possible. \$\endgroup\$ Commented Jan 30, 2014 at 4:58
0
\$\begingroup\$

Assuming that the CPU supports nested interrupts, and nested interrupts are enabled, and the higher priority interrupt is enabled, when the higher priority interrupt fires then CPU behaviour will be exactly as you would expect: CPU context will be pushed onto the stack and the execution point will jump to the new interrupt vector. When the higher-priority interrupt completes, CPU context will be retrieved from the stack and the execution point will return to wherever it was in the low-priority interrupt.

\$\endgroup\$
4
  • 1
    \$\begingroup\$ You are correct, but I think Swanand wanted to know WHO takes care of all this pushing and popping. In an RTOS context it is RTOS code, without an RTOS it is generally up to the author of the interrupt routine. \$\endgroup\$ Commented Jan 29, 2014 at 10:59
  • \$\begingroup\$ @Wouter ... or up to the compiler \$\endgroup\$
    – m.Alin
    Commented Jan 29, 2014 at 12:01
  • \$\begingroup\$ But then it would be still up to the author to instruct the compiler to do so with [[interrupt]] or something similar. \$\endgroup\$ Commented Jan 29, 2014 at 12:14
  • \$\begingroup\$ This answer is a bit misleading. You say the CPU context will be pushed onto the stack. Not only are you assuming the existance of a stack known to the hardware, but you haven't defined what that context is. At minimum, the CPU has to save the return address somewhere somehow. Some processors save other state, and in various ways. However, that may all be quite different from the "state" the interrupted program is using. You can't assume the hardware takes care of all this for you, as your answer suggests. \$\endgroup\$ Commented Jan 29, 2014 at 13:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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