Interrupts — ISR design, NVIC priority, interrupt latency: Visual walkthrough

5.5.7 · D2 · Coding › Embedded Systems & Real-Time Software › Interrupts — ISR design, NVIC priority, interrupt latency

Yeh parent Interrupts note ka visual companion hai. Agar koi word naya lage, toh woh usi waqt define hoga jab woh aayega.

Step 0 — woh words jo hum use karenge (pehle seekho, phir draw karo)

Hum inhe ek horizontal time arrow par rakhenge: left = doorbell bajti hai, right = tumhare handler ka pehla instruction run hota hai. Us arrow ki length hi latency hai.

Step 1 — event fire hua, par CPU busy hai

KYA. Kisi ek pal, ek peripheral apna interrupt wire high karta hai. CPU mid-instruction hai — shayad kisi slow instruction ke beech mein.

YEH KYUN MATTER KARTA HAI. CPU ko zyaadatar instructions beech mein abandon karna allowed nahi hai. Use pehle ek clean stopping point tak pahunchna hoga. Toh humari latency ka sabse pehla hissa hai current instruction finish hone ka intezaar.

PICTURE. Red bolt event hai. Blue block woh instruction hai jo abhi bhi execute ho raha hai. Unke beech ka gap hamara pehla cost hai, $t_{finish-instr}$ .

Figure — Interrupts — ISR design, NVIC priority, interrupt latency

Step 2 — par kya interrupts abhi allowed bhi the?

KYA. Kuch bhi hardware-wala hone se pehle, hum poochhte hain: kya programmer ne interrupts mask (band) kar rakhe hain? Code aksar yeh critical section ke around karta hai — kuch lines jo disturb nahi honi chahiye.

KYUN. Agar interrupts masked hain, toh doorbell ignore hoti hai jab tak woh wapas on nahi ho jaate. Event intezaar karta rehta hai. Yeh woh cheez hai jo tum, programmer, control karte ho — sabse zyada.

PICTURE. Orange bar woh critical section hai jahan interrupts off hain. Event (red bolt) uske andar girti hai, toh woh bar khatam hone tak wait karti hai.

Step 3 — NVIC notice karta hai aur decide karta hai

KYA. Jab interrupts allowed ho jaate hain, NVIC (traffic-controller peripheral) pending request dekhta hai, uski priority ko jo chal raha hai usse compare karta hai, aur decide karta hai "haan, preempt karo."

ALAG STEP KYUN. Notice karna instant nahi hota. NVIC ko incoming signal synchronise karne aur comparison run karne ke liye kuch clock ticks chahiye. Bahut chota, par real hai.

PICTURE. Gray gear NVIC ka decision hai. Dekho yeh slice pehle wali slices ke compare mein kitni choti hai.

Recall Priorities compare kyun karte hain?

Agar do doorbells ek saath bajein, toh kisi ko haarna hoga. NVIC priority (lower number = zyada urgent) use karta hai ek winner chunne ke liye aur yeh decide karne ke liye ki koi naya IRQ running wale par barge in kar sakta hai ya nahi. Poori mechanics parent note aur ARM Cortex-M Architecture mein hai.

Step 4 — stacking: CPU tumhari jagah free mein save karta hai

KYA. ISR par jump karne se pehle, hardware automatically 8 registers stack par push karta hai: $R 0, R 1, R 2, R 3, R 12, L R, P C, x P S R$ .

KYUN. ISR abhi CPU ke scratch registers par likhne wala hai. Interrupted code ko baad mein perfectly resume karne ke liye, CPU pehle "caller-saved" registers ka snapshot leta hai. Kyunki hardware yeh karta hai, tumhari ISR ek plain C function ho sakti hai — koi assembly nahi chahiye.

PICTURE. Aath boxes stack par slide karte hain, ek per register. Har box ek memory write hai (~ek cycle plus thoda sa).

Step 5 — vector fetch: main jump kahaan karun?

KYA. CPU vector table (handler addresses ka ek plain array) se ISR ka address padhta hai aur use program counter $P C$ mein load karta hai.

KYUN. CPU ko pata nahi hota ki tumhara handler memory mein kahan hai. Vector table lookup hai: interrupt number → address. Woh address fetch karne mein kuch cycles lagte hain.

PICTURE. Table ke slot "IRQ #k" se $P C$ register mein ek arrow. Jis pal $P C$ mein address aa jaata hai, latency khatam hoti hai.

Step 6 — poora formula assemble karo

KYA. Har ek slice jo humne draw ki, left se right tak, ek number mein add karo.

KYUN. Latency independent delays ka sum hai. Hamare model mein kuch overlap nahi hota — har stage doosre ke shuru hone se pehle finish honi chahiye — toh hum sirf add karte hain.

PICTURE. Poora timeline, pehle steps se color-matched, end to end stacked.

Step 7 — numbers daalo (worked case)

KYA. Ek concrete worst case compute karo.

KYUN. Ek formula jisme tum numbers nahi dal sakte woh real-time design ke liye bekar hai. Hume ek actual nanosecond count chahiye deadline ke against check karne ke liye (dekho Real-Time Scheduling & Deadlines).

Diya gaya: clock $= 100 MHz$ , toh $1 cycle = 10 ns$ . Hardware part $= 12$ cycles. Tumhara sabse lamba critical section interrupts ko $50$ cycles ke liye mask karta hai.

$t_{lat,worst} = (hardware 12 + t_{blocked} 50) \times 10 ns = 62 \times 10 ns = 620 ns$

$12$ ::: fixed hardware cost (detect + finish + stack + vector, lumped).
$50$ ::: worst-case masking, agar event ek cycle baad fire hoti hai jab tumne interrupts disable kiye.
$\times 10 ns$ ::: cycles → time convert karo $100 MHz$ par.

PICTURE. 12-cycle hardware block, 50-cycle blocking block se chhota dikha raha hai — yeh ek visual argument hai critical sections chote rakhne ke liye.

Step 8 — degenerate & edge cases (kabhi mat skip karo)

KYA. Extremes par kya hota hai?

KYUN. Real systems corners mein lete hain. Agar tum sirf average case samajhte ho, toh ek rare event tumhari deadline tod deta hai.

Ek-picture summary

Poori derivation compress karke: event fire hoti hai, koi bhi masking aur current instruction wait karti hai, NVIC decide karta hai, hardware 8 registers stack karta hai aur vector fetch karta hai — aur tab, aur sirf tab, tumhare handler ka pehla instruction run hota hai. Slices add karo, cycles ko nanoseconds mein convert karo, ho gaya.

Recall Feynman retelling — ek dost ko simple words mein explain karo

Socho ek worker (CPU) ek list se chores kar raha hai. Ek ghanti bajti hai (ek event). Pehle, agar worker ne sabko bola tha "ek minute mujhe mat bajao" (masked interrupts), toh ghanti bas wait karti hai — yeh sabse bada chunk hai aur yeh worker ki khud ki galti hai, toh woh "quiet minutes" chote rakho. Phir, worker ko woh ek chore finish karna hoga jo haath mein hai (aadha-adhoora division nahi chhod sakte). Phir ek manager (NVIC) kuch seconds leta hai confirm karne ke liye "haan, jaao jawab do, yeh kaafi important hai." Jaane se pehle, worker exactly note kar leta hai ki woh kya kar raha tha ek sticky-note pad par (8 registers stack karta hai) taaki woh perfectly wapas aa sake. Phir woh dekh leta hai ki kaun sa darwaza jawab dena hai (vector fetch). Sirf ab woh naya kaam shuru karta hai — aur wahi shuruat hai jahan latency khatam hoti hai. Saari choti waits add karo, aur agar clock $100$ million ticks per second hai, toh har tick $10 ns$ hai. Baarah unavoidable hardware ticks plus jitni der tumhari "quiet minute" chali — yahi tumhara number hai.

Recall Quick self-test

Ek $200 MHz$ CPU, $12$ -cycle hardware part, worst critical section $= 88$ cycles. Worst-case latency? ::: $1 cycle = 1/200 MHz = 5 ns$ ; $(12 + 88) \times 5 = 100 \times 5 = 500 ns$ .