How RTOS does task switching from interrupt

Question

Suppose there is two task running TASK_A and TASK_B. While TASK_A is running an interrupt occurred and a context switch to TASK_B is needed.

While inside ISR, TASK_B

Answer 1

The ISR has to be implemented in a way that allows for a context switch. Typically, at the end of the ISR there will be a call to an RTOS function that checks for and performs the context switch.

When the interrupt occurs, the CPU saves its context and jumps to the ISR. The way the context is saved varies among CPU families. When the ISR is complete, it should call a special RTOS routine that allows for a context switch after an ISR. If there is a higher priority task ready to run then this routine will perform a context switch. It will take the pre-interrupt context saved by the CPU and save it with TASK_A. Then it will get the saved context of TASK_B and restore it into the CPU such that when the end-of-interrupt instruction is called, execution returns to the context of TASK_B.

The details of all of this is very CPU and RTOS dependent.

Answer 2

An RTOS will require specific ISR entry/exit code to be included in each ISR that may cause a context switch (typically any that call the RTOS API). These functions maintain a counter that allows nested interrupts; when the counter is decremented to zero, the outermost ISR is about to return, and the exit code invokes the kernel scheduler.

The scheduler will restore the context to the highest priority ready task; this includes modifying the return address so that the RETI instruction causes the program counter to be set to TASK_B's restart point rather the TASK_A. The scheduler will store the TASK_A restart point in the task control block(TCB) so that its context can be similarly restored.