Electronic – Preemptive Interrupts and “Context Switching”

Here's the trick:

• You configure your "extra-low priority interrupt" as normal low pri interrupt: set up the vector, activate the interrupt, all the standard stuff.
• Write the handler procedure at an arbitrary address as usual. Standard interrupt restrictions apply - saving/restoring registers, stack discipline etc. End it with RET, not RETI.
• At the interrupt vector address perform three operations:
  • push lower byte of your handler address
  • push higher byte of your handler address
  • RETI

That way, the interrupt flag is cleared and normal execution is resumed, but not from the address where the interrupt occurred, but from your handler vector. You can perform the rest of the interrupt activity and then just resume the main loop from where it was interrupted by performing a standard RET - the address stored by the interrupt on stack is still there.

There isn't a fundamental difference, it's more a question of degree — the amount of context that needs to be saved.

When an RTOS thread context switch occurs, all of the CPU state that any thread might use must be saved. This usually includes all of the CPU registers, including flag or status registers, so that when they're restored, the thread resumes as though nothing ever happened.

When an interrupt occurs, there's still a context switch, but only the context that the interrupt handler actually needs to use needs to be saved and then subsequently restored. If you write your interrupt handler in a high-level language, this will pretty much be equivalent to a full thread context switch, because there are no constraints on what resources such an interrupt handler might touch. However, if you write your interrupt handler in assembly language, you can keep track of exactly which registers it touches and save only those. This allows the execution of the interrupt handler to be extremely fast, reducing its impact on the rest of the system, and/or allowing it to handle interrupts at a higher rate.