Step-by-step (ARM Cortex-M style), and why each step:
A trigger occurs — a tick interrupt, or xSemaphoreGive unblocks a higher task.
Why: this is the moment the scheduler must re-evaluate "who is highest-priority Ready?"
CPU enters the PendSV handler (the dedicated switch interrupt).
Why: PendSV is set to the lowest interrupt priority so the switch only happens after all real ISRs finish — avoiding nested mess.
Save context of the outgoing task: push r4–r11 onto its stack. (Hardware already auto-pushed r0–r3, r12, LR, PC, xPSR on exception entry.)
Why: together this captures the full state; hardware does half, software does the rest.
Store the outgoing task's final SP into its Task Control Block (TCB).
Why: the TCB is the per-task bookkeeping record; SP is the handle to its whole saved frame.
Scheduler picks the next TCB (highest-priority Ready). Load its saved SP.
Restore context: pop r4–r11 from the new task's stack; exception return auto-restores the rest, jumping to the new task's PC.
Why: the new task's PC was saved last time it was switched out, so it resumes seamlessly.
The scheduler forcibly pausing a running task the moment a higher-priority task becomes Ready, without the task's cooperation.
What does a context switch save and restore?
All CPU registers (general regs, status flags, PC) plus the stack pointer, anchored via each task's TCB.
What rule does a fixed-priority preemptive scheduler follow?
Always run the highest-priority task that is in the Ready state.
Formula for CPU fraction lost to context switching?
η=Tcs⋅ftick (worst case, one switch per tick).
Why is busy-waiting bad in an RTOS?
The task stays Running and hogs the CPU; it never enters Blocked, so lower-priority but useful work can't run. Use a blocking call instead.
How do equal-priority tasks share the CPU (not preemption)?
Time-slicing / round-robin at tick boundaries.
Why is PendSV given the lowest interrupt priority on Cortex-M?
So the context switch runs only after all real ISRs finish, avoiding nested-switch corruption.
What is a TCB?
Task Control Block — per-task record holding its saved stack pointer, priority, state, and bookkeeping.
Cooperative vs preemptive scheduling?
Cooperative: task keeps CPU until it voluntarily yields. Preemptive: scheduler can interrupt it anytime for a higher-priority task.
Recall Feynman: explain to a 12-year-old
Imagine one teacher (the CPU) and many kids (tasks) who all need help. The teacher can help only one kid at a time, but switches super fast so it looks like everyone gets help at once. A class monitor (the scheduler) always sends the teacher to the kid with the most urgent problem first — even pulling the teacher away mid-sentence from a less urgent kid (that's preemption). Each time the teacher switches kids, they jot down a sticky note of exactly where they stopped (context switch / saving registers) so they can continue later without confusion.
Dekho, ek CPU ek time pe sirf ek hi kaam (instruction) kar sakta hai. Lekin embedded system me bahut saare kaam ek saath karne ka feel chahiye — sensor padho, LED blink karo, WiFi se baat karo. Yahi kaam RTOS karta hai: pure program ko chhote-chhote independent tasks me todta hai, aur ek scheduler decide karta hai ki abhi kaunsa task CPU lega. Rule simple hai: jo task Ready hai aur sabse high priority ka hai, wahi chalega — code ka order matter nahi karta.
Preemption ka matlab hai: agar koi low-priority task chal raha hai aur achanak koi high-priority task Ready ho gaya (jaise button dab gaya), to scheduler low task ko beech me hi rok dega aur high task chalu kar dega. Bina rukne wale (cooperative) system me task khud "yield" kare tabhi switch hota — jo deadline miss kara sakta hai. Isliye real-time systems me preemptive scheduling use hota hai.
Jab bhi ek task se dusre task pe jaate hain, context switch hota hai. Iska matlab — CPU ke saare registers (PC, stack pointer, general registers) ko purane task ke stack me save karte hain, aur naye task ke registers wapas load karte hain. Isse har task ko lagta hai ki CPU sirf uska hi tha, aur wo exactly wahin se continue karta hai jahan ruka tha. Ye saari bookkeeping TCB (Task Control Block) me hoti hai.
Important baat: zyada tasks banane se speed nahi badhti (core to ek hi hai), sirf switching overhead aur RAM badhta hai. Aur tick frequency zyada karne se system "zyada real-time" nahi hota — overhead η=Tcs×ftick se CPU waste hota hai. Asli trick hai: tasks ko block karwao (busy-wait mat karo), taaki jab ek task wait kar raha ho, dusra useful kaam kar sake.
