Interrupts — ISR design, NVIC priority, interrupt latency: Question bank

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

Ground-work: woh words jinpar ye traps rely karte hain

Questions se pehle, do chhoti pictures. Agar ye tumhe pehle se achhe se pata hain, skip karo — lekin neeche ke har trap ka inpar hi tika hua hai.

Definition Woh registers jo hardware stack karta hai (aur "caller/callee saved" ka matlab)

Ek register CPU ke andar ek tiny, super-fast storage slot hota hai (RAM se bahut zyada fast). Jab interrupt fire hota hai, inhe save karna padta hai taaki interrupted code bina kisi takleef ke resume ho sake. Woh set jo Cortex-M hardware automatically save karta hai:

$R 0$ – $R 3$ ::: char general-purpose scratch registers jo C compiler arguments pass karne aur temporary values rakhne ke liye use karta hai.
$R 12$ ::: ek aur scratch register (the "intra-procedure scratch").
$L R$ (Link Register) ::: return address hold karta hai — jab function finish ho tab kahan jump karna hai.
$P C$ (Program Counter) ::: us instruction ka address hold karta hai jo abhi execute ho rahi hai — "code mein hum kahan hain."
$x P S R$ (Program Status Register) ::: status flags hold karta hai (result zero tha, negative tha, carry tha, etc.).

Caller-saved ka matlab hai: ARM calling convention ke hisaab se ye registers koi bhi function freely clobber kar sakta hai, isliye jo function call karta hai use inhe save karna hoga agar usse baad bhi inki zaroorat hai. Hardware exactly yahi set stack karta hai taaki ISR ek ordinary C function ban sake. Callee-saved ( $R 4$ – $R 11$ ) ka matlab hai ki called function promise karta hai inhe preserve karega, isliye compiler inhe tabhi save karta hai jab ISR actually inhe use kare.

Definition Timing terms (the latency budget)

Interrupt latency woh time hai jab se event assert hoti hai tab se ISR ki pehli instruction run hone tak. Hum har slice ko naam dete hain taaki traps usse point kar sakein. Ek stopwatch imagine karo jo in phases se guzarta hai (neeche figure dekho):

$t_{detect}$ ::: woh kuch cycles jo NVIC ko asserted line ko notice aur register karne mein lagte hain (synchronisation delay).
$t_{finish-instr}$ ::: CPU ko ek interruptible point tak pahunchne ka time — agla callout dekho.
$t_{stack}$ ::: upar ke 8 registers ko stack par push (stack) karne ka time — "hardware stacking."
$t_{vector}$ ::: vector fetch — hardware ISR ka address vector table se padhta hai taaki use pata chale kahan jump karna hai.
$t_{blocked}$ ::: koi bhi time jab interrupt masked tha (critical section ne disable kiya tha) ya kisi equal/higher-priority ISR ke peeche wait kar raha tha jo already run ho rahi thi.

Definition "Interruptible point", "vector fetch", "hardware stacking" seedhe shabdon mein

Hardware stacking ::: CPU circuitry khud (tera code nahi) 8 caller-saved registers ko stack par push karta hai — automatic aur fixed-time.
Vector fetch ::: vector table (ISR addresses ki ek array) mein ISR ka memory address dhundhna aur use $P C$ mein load karna.
Interruptible point ::: instructions ke beech ka woh moment jahan CPU ruk sakta hai. Zyaadatar instructions interruptible hoti hain — CPU interrupt le sakta hai jaise hi woh khatam hoti hain. Kuch multi-cycle instructions (jaise integer division, ya multi-register load/store) kai cycles tak chalti hain; CPU ya toh unhe finish hone deta hai ya restart karta hai, isliye agar koi abhi start hui hai, interrupt uska intezaar karta hai. Woh wait $t_{finish-instr}$ hai.

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

Upar ka figure woh 12-cycle deterministic hardware part hai jiska traps mein reference hai: Cortex-M3/M4 par bina wait states ke, $t_{detect} + t_{stack} + t_{vector}$ us mashoor 12 cycles par aata hai. Latency mein baaki sab ( $t_{finish-instr}$ aur khaaskar $t_{blocked}$ ) variable hai aur tera code decide karta hai.

True ya false — justify karo

Cortex-M par higher priority number ka matlab zyada urgent interrupt hota hai.

False — NVIC par lower numeric value = higher urgency, isliye priority 0 sabse zyada urgent hai. Ye everyday "level 10 beats level 1" intuition ka ulta hai.

Sub-priority ek interrupt ko doosre ko mid-execution preempt karne de sakti hai.

False — sub-priority sirf ek tiebreaker hai jab do equal-preemption interrupts ek hi waqt pending hon; ye kabhi preemption nahi karta. Sirf ek higher preemption priority hi running ISR ko interrupt kar sakti hai.

Ek ISR hamesha completion tak execute hoti hai pehle koi aur interrupt run kar sake.

False — ye sirf equal ya lower priority ke liye sach hai. Ek higher preemption-priority interrupt running ISR ko preempt (nest into) kar sakta hai; wahi nesting NVIC ka poora point hai.

Interrupts har situation mein polling se strictly faster hote hain.

False — ek aise device ke liye jo hamesha ready hai (ek tight, high-rate stream jise tum continuously service karo), polling lower-overhead ho sakti hai kyunki har event par stacking aur vector-fetch ka cost nahi lagta. Interrupts jab sporadic events hon tab jeette hain jab otherwise check karne mein cycles barbaad hote.

Hardware stacking ka matlab hai ISR mein registers save karne ki chinta kabhi nahi.

False — hardware automatically upar define kiya caller-saved set (

R 0

–

R 3

R 12

L R

P C

x P S R

) auto-stack karta hai. Agar tumhari ISR callee-saved registers (

R 4

–

R 11

) use kare, toh compiler unhe save/restore karne ka code emit karta hai; tum ISR ko normal C function likhkar compiler par rely karte ho.

volatile keyword shared variable ke access ko atomic banata hai.

False — volatile sirf compiler ko har baar memory se re-read karne par majboor karta hai (register mein caching ko defeat karta hai). Ye tumhe koi atomicity nahi deta; ek multi-byte variable mid-update torn ho sakta hai. Concurrency & Race Conditions dekho.

Tail-chaining do pending interrupts ke run hone ka logical order change karta hai.

False — ye sirf back-to-back ISRs ke beech barbaad hone wala unstack-then-restack hataata hai. Order abhi bhi priority se decide hota hai; tail-chaining ek pure latency optimization hai, scheduling change nahi.

12-cycle Cortex-M figure (upar ka diagram dekho) woh total latency hai jo actually observe hogi.

False — 12 cycles sirf deterministic hardware part hai (

t_{detect} + t_{stack} + t_{vector}

, bina wait states ke). Real latency mein

t_{finish-instr}

aur koi bhi

t_{blocked}

(interrupts masked, ya higher/equal-priority ISR already run ho rahi) bhi jud jaata hai.

Error dhundho

Ek engineer ISR ke andar peripheral ka interrupt flag clear karna bhool jaata hai. Kya toot jaata hai?

Interrupt line asserted rehti hai, isliye jaise hi ISR return karti hai NVIC use still pending dekhta hai aur turant re-enter karta hai — ek practically infinite ISR loop jo main code ko starve karta hai.

Code while(!flag); karta hai jahan flag ek plain int hai jo ISR set karta hai. Ye forever kyun hang kar sakta hai?

Compiler flag ko pehle read par register mein cache karta hai aur RAM dobara nahi dekhta, isliye use ISR ki write kabhi nahi dikhti. Isse ==volatile== mark karo taaki har read memory hit kare.

Ek ISR event log karne ke liye printf() call karta hai. Design flaw kya hai?

printf long-running hai, block kar sakta hai, aur aksar non-reentrant hai; ise ISR mein run karna har equal/lower-priority interrupt ki latency badhaata hai aur shared library state corrupt kar sakta hai. Ek flag set karo aur main loop ko log karne do.

Main loop ek 32-bit counter padhta hai jo ISR update karta hai, ek chip par jahan read ek instruction hai. Ye abhi bhi volatile mark hai lekin IRQs disable kiye bina padha gaya hai — safe hai?

Agar read ek single atomic access hai toh tearing ke liye theek hai, lekin agar tum counter do baar padho (jaise compare phir use) toh ISR reads ke beech ise change kar sakta hai. Atomicity poore logical operation ke baare mein hai, sirf ek instruction ke baare mein nahi.

Ek designer UART-receive IRQ ko low urgency (bada number) deta hai kyunki "logging critical nahi hai," lekin bytes drop hoti rehti hain. Reasoning kahan galat hai?

Bytes drop hona ek latency/deadline problem hai, content-ki-importance ki problem nahi. Dheere service hone wala receive IRQ apna hardware buffer overrun karta hai; fix hai ek high urgency short ISR jo bytes ek ring buffer mein daalti rahe.

Do interrupts same preemption priority share karte hain; designer expect karta hai ki higher sub-priority wala doosre ko interrupt karega. Ye kyun nahi hoga?

Equal preemption priority ka matlab hai koi bhi doosre ko preempt nahi kar sakta — sub-priority sirf decide karta hai kaun pehle jaata hai jab dono simultaneously pending hon. Ek baar koi run ho raha hai, doosre ko return hone tak wait karna hoga.

Koi ek large data-processing block ko __disable_irq() mein "safe rehne ke liye" wrap karta hai. Iska kya cost hai?

Har interrupt poore block ke liye masked ho jaata hai, isliye

t_{blocked}

— aur isliye worst-case latency — us block ki length tak badh jaati hai. Critical sections short aur bounded hone chahiye; sirf un chand instructions ke around IRQs disable karo jo actually shared state ko touch karte hain.

Why questions

Hardware registers automatically kyun stack karta hai ISR code par chhode bina?

ISR ko ek plain C function banane ke liye aur latency ko deterministic banane ke liye — CPU fixed hardware time (

t_{stack}

) mein immediately stacking shuru kar sakta hai rather than variable software prologue ka wait karne ke.

Priority value ko preemption aur sub-priority fields mein split kyun karte hain?

Ye do alag sawaalon ke jawaab dete hain: "kaun kis ko interrupt kar sakta hai" (preemption) aur "bina preemption ke tie mein kaun jeetta hai" (sub-priority). Ties ko non-preempting rakhna equally-urgent handlers ke beech faaltu context switches se bachata hai.

ISR-shared data ki guard karne wali critical section jitna ho sake utni short kyun honi chahiye?

Kyunki iske andar interrupts masked hain, isliye koi bhi event mid-section pahunchne par stacking shuru hone se pehle poori section length ko

t_{blocked}

mein jod deti hai — latency inflate karti hai aur missed deadlines ka risk badhaati hai. Real-Time Scheduling & Deadlines dekho.

Ek long division instruction latency kyun badha sakti hai jabki tumhari ISR short hai?

Division ek multi-cycle instruction hai, isliye beech mein interruptible point nahi hai; CPU ko ise finish (ya restart) hone dena padta hai interrupt lene se pehle. Woh wait

t_{finish-instr}

hai, aur ye is baat se independent hai ki tumhari ISR kitni short hai.

Hum heavy work main loop par kyun defer karte hain ISR mein karne ke bajaye?

Ek long ISR apni poori duration ke liye har equal/lower-priority interrupt ko block karta hai. Minimum karna (data lo, flag set karo) sab ke liye latency low aur bounded rakhta hai; non-time-critical kaam phir wahan hota hai jahan preemption cheap hai.

Tail-chaining cycles kyun bachata hai jab do IRQs back-to-back hon?

Stack par pehle se rakhte 8-register context valid hai, isliye ise sirf dobara push karne ke liye pop karna barbaad kaam hai — hardware handler-to-handler seedha jump karta hai (~6 cycles instead of ~24).

Interrupts average power draw kyun kam kar sakte hain?

Ye CPU ko sleep karne aur event se wake hone dete hain rather than polling loop mein spinning ke, isliye woh zyada time low-power sleep mode mein bitaata hai instead of ek aise device ko check karne mein cycles jaalaane ke jo ready nahi hai.

Edge cases

Kya hota hai agar interrupt exactly tab fire ho jab critical section ne ise mask kiya hua ho?

Ye NVIC mein pending ho jaata hai aur yaad rakhha jaata hai. Jis pal mask hata, use le liya jaata hai — isliye event miss nahi hoti, lekin tum poori critical-section time ko added

t_{blocked}

ke roop mein pay karte ho.

Equal preemption aur equal sub-priority wale do interrupts saath aate hain — tie kaise toota jaata hai?

Koi user-programmable tiebreaker nahi bachi, isliye NVIC ek fixed rule par fall back karta hai: lower exception/IRQ number wala pehle service hota hai.

Agar ek higher-priority interrupt tezi se baar baar fire karta rahe, lower-priority ke saath kya hota hai?

Use starve kiya ja sakta hai — perpetually preempted aur aage badhne ka mauka nahi milta. Ye ek real-time hazard hai; tum ise bounded high-priority ISRs ya fast source par rate limiting se bachate ho.

Kya ek interrupt us ISR ko preempt kar sakta hai jiske khud ke saath same preemption priority hai?

Nahi — equal preemption priority ka matlab hai koi nesting nahi. Ye pending wait karta hai jab tak running ISR return na kare, chahe iska sub-priority "higher" ho.

Kisi interrupt ki latency kya hogi jo tab aata hai jab kuch nahi chal raha aur kuch masked nahi hai?

Essentially pure deterministic hardware minimum (

t_{detect} + t_{stack} + t_{vector}

, upar dikhaye Cortex-M3/M4 par ~12 cycles), kyunki

t_{blocked}

zero hai aur koi lambi instruction finish karne ki zaroorat nahi.

Agar ISR interrupts re-enable kare aur phir ek higher-priority IRQ isme nest kare, stack par kiska stacked context hai?

Dono ka — original interrupted code ka context (

R 0

–

R 3

R 12

L R

P C

x P S R

) tab stack hua jab pehli ISR enter hui, aur pehli ISR ka context tab stack hua jab nested wali enter hui. Unstacking har return par last-in-first-out order mein unwind karta hai.

Recall Jaane se pehle ek-line self-check

Lower number = zyada urgent; ISRs short aur bounded; shared vars volatile aur atomic; latency = deterministic 12-cycle hardware part plus $t_{finish-instr}$ aur jo bhi tune block kiya ( $t_{blocked}$ ). Question ::: Agar chaaron obvious lagte hain, tune traps ko hara diya.