5.5.7 · D4 · HinglishEmbedded Systems & Real-Time Software

ExercisesInterrupts — ISR design, NVIC priority, interrupt latency

3,390 words15 min read↑ Read in English

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


Level 1 — Recognition

L1.1 — Vocabulary match

Problem. Har phrase ke liye parent note se term batao: (a) "hardware automatically 8 registers save karta hai tumhara code chalane se pehle," (b) "ISR addresses ka array jisme hardware index karta hai," (c) "wo peripheral jo decide karta hai kaun sa interrupt chalega aur kis priority par."

Recall Solution (L1.1)

(a) Stacking — CPU auto-push karta hai , , (link register, return address), (program counter, aage kya chalta hai), aur (upar define kiya gaya Program Status Register) — kul 8 words — stack par. "For free" kyun? Kyunki ye caller-saved hain, tumhara ISR (Interrupt Service Routine) ek plain C function ho sakta hai. (b) Vector table — ISR start addresses ka ek array; NVIC interrupt number ko index ki tarah use karta hai. (c) NVIC (Nested Vectored Interrupt Controller).

L1.2 — Kaun sa number jeetta hai?

Problem. Do interrupts pending hain: IRQ-X ki priority number hai, IRQ-Y ki priority number hai. Cortex-M par kaun zyada urgent hai?

Recall Solution (L1.2)

IRQ-X (number ). Kyun? Cortex-M par, ==lower numeric value = higher urgency==; priority sabse urgent hoti hai. Ye rozmarra ki "level 10 beats level 1" wali soch ka ulta hai — neeche L1 mistake dekho.


Level 2 — Application

L2.1 — Cycles ko time mein convert karo

Problem. Ek Cortex-M4 MHz par chalta hai. Deterministic hardware interrupt entry ka cost cycles hai. Ise nanoseconds mein convert karo.

Recall Solution (L2.1)

Ek cycle: . Multiply kyun karte hain? Latency count karta hai kitne clock ticks guzre, aur har tick last karta hai; total time hai (count) × (time per tick).

L2.2 — Priority-level counting

Problem. Ek chip priority bits implement karta hai. PRIGROUP bits preemption ko assign karta hai. Kitne preemption levels aur kitne sub-priority levels hain? Total verify karo.

Recall Solution (L2.2)

Upar derive kiye rule ka use karte hue, aur , , ke saath:

  • Preempt levels . Kyun? bits distinct groups encode karte hain jo ek doosre ko preempt kar sakte hain.
  • Sub levels . Kyun? bacha hua bit tiebreaker slots encode karta hai.
  • Total . ✔ Split kabhi levels create ya destroy nahi karta.

L2.3 — Worst-case latency

Problem. CPU MHz. Hardware entry cycles. Tumhara sabse lamba critical section cycles ke liye interrupts mask karta hai. Worst-case latency nanoseconds mein compute karo.

Recall Solution (L2.3)

Figure — Interrupts — ISR design, NVIC priority, interrupt latency
Upar ka timeline padho: event masked window ke andar fire karta hai, toh "ISR kab start ho sakta hai?" ka clock tab tak hardware entry ke through tick karna shuru nahi kar sakta jab tak mask lift nahi ho jaata. Do red/amber bars end-to-end hain, overlapping nahi. . kyun add karte hain? Worst case hai event ka thik baad fire karna jab tune interrupts mask kiye — ise hardware stacking shuru hone se pehle poora critical section wait karna padta hai. Critical section ka idea dekho.


Level 3 — Analysis

L3.1 — Kya X, Y ko preempt karta hai?

Problem. Chip mein bits hain, PRIGROUP → preempt bits, sub bit. IRQ-A: preempt , sub . IRQ-B: preempt , sub . IRQ-C: preempt , sub . Jawab do: (a) Kya A, running B ko preempt karta hai? (b) Agar B aur C simultaneously pending hain (koi nahi chal raha abhi), kaun pehle chalta hai, aur kya wo doosre ko preempt karta hai?

Recall Solution (L3.1)

Figure — Interrupts — ISR design, NVIC priority, interrupt latency
Figure kaise padhen: neeche wala cyan band IRQ-B execute hota hua dikhata hai; jab amber IRQ-A bar aata hai, B ka band pause ho jaata hai (wahan ek gap hai) — ye gap preemption ka visual proof hai. B sirf A ki amber bar khatam hone ke baad resume karta hai. IRQ-C, B ki preemption priority share karta hua, right mein queue mein baitha hai aur kabhi apna overlapping band nahi paata, kyunki wo kisi running peer mein kabhi cut nahi kar sakta. (a) Haan. Preemption sirf preemption priority se decide hoti hai. A ka preempt hai, B ka preempt ; lower number = higher urgency, toh A, B ko mid-execution interrupt kar sakta hai. (b) B pehle chalta hai, aur wo C ko preempt NAHI karta. B aur C same preemption priority () share karte hain, toh koi bhi doosre ko interrupt nahi kar sakta. Unka sub-priority pending tie break karta hai: B sub , C sub ko beat karta hai (lower = pehle). Jab B complete ho jaata hai, C chalta hai. Sub-priority kabhi preempt kyun nahi karta: ye sirf queue mein already waiting cheezein order karta hai; ek running ISR ko rokne ki iske paas koi power nahi hai.

L3.2 — Tail-chaining ki bachat

Problem. Do interrupts B phir C back-to-back pending hain. Naive handling: B ke baad unstack ( cyc) phir C ke liye re-stack ( cyc). Tail-chaining B→C transition ke liye sirf cyc cost karta hai. (a) Kitne cycles bachte hain? (b) Unstack+restack skip karna kyun safe hai?

Recall Solution (L3.2)

Figure — Interrupts — ISR design, NVIC priority, interrupt latency
Figure kaise padhen: upar wali row naive path hai — "B body" ke baad ek wide amber block (unstack + restack ) "C body" shuru hone se pehle burn hota hai. Neeche wali row tail-chaining hai — same "B body" ek narrow amber block (chain ) ke through seedha "C body" mein flow karta hai. Do amber blocks ki width ka difference hi bachat hai, jo neeche amber mein call out ki gayi hai. (a) Naive transition cost cyc. Tail-chained cyc. Bachat cyc. (b) Stack par 8-register saved context B ke return hote hi still valid hai — beech mein ISRs ke bahar kuch nahi chala. Un 8 words ko pop karna sirf immediately identical 8 words push karne ke liye pure wasted work hai, toh hardware seedha B→C jump karta hai, stack frame ko jagah par rakhta hua.


Level 4 — Synthesis

L4.1 — UART receive ISR design karo

Problem. Bytes ek UART par baud par aate hain, bits per byte (start + 8 data + stop). (a) Kitne bytes per second, aur inter-byte time budget µs mein kya hai? (b) ISR ko minimum kya kaam karna chahiye taaki wo budget mein rahe, aur heavy parsing kahan jaayegi?

Recall Solution (L4.1)

(a) Byte rate bytes/sec. Time budget per byte s µs. Toh ISR + baaki sab kuch ek byte handle karna complete kar le agle ke aane se pehle. (b) Minimum ISR work: (1) pehle RX interrupt flag clear karo pehle (taaki wo forever re-enter na ho), (2) data register se received byte padho (ye real hardware par flag bhi often clear karta hai), (3) ise ek ring buffer mein push karo, (4) ek volatile "data ready" flag set karo, (5) return karo. Heavy work (protocol parsing, checksums, string handling) main loop mein jaata hai — deferred / bottom-half mein. Split kyun karte hain? Lamba ISR har equal/lower-priority interrupt ki latency badhata hai; ise ek muthi bhar instructions par rakhne se µs budget mein agla byte aur baaki IRQs ke liye kaafi jagah bachti hai.

L4.2 — Teen tasks ke liye priorities choose karo

Problem. Tumhare paas teen interrupt sources hain: ek motor safety-stop line (instantly react karna zaroori), ek kHz control timer (hard deadline), aur ek UART byte (soft — ring buffer jitter absorb karta hai). Chip mein bits hain, saare preemption ke liye use hote hain (PRIGROUP → preempt bits, sub bits). Preemption priority numbers assign karo aur justify karo.

Recall Solution (L4.2)

preempt bits ke saath levels hain, numbers (top) … .

  • Motor safety-stop → priority . Sabse time-critical; sab kuch preempt karna zaroori. Yaad rakho tightest deadline ko highest urgency milti hai.
  • kHz control timer → priority . Hard periodic deadline; UART ko preempt karna zaroori lekin safety stop ke aage yield karna.
  • UART byte → priority (ya higher number). Ring buffer jitter tolerate karta hai, toh ye dono ke peeche wait kar sakta hai — iska latency briefly badhna harmless hai. Ye order kyun? Lower number = sabse zyada chillaata hai. Numbers assign karo "late reaction se kitna nuksaan hoga?" ke order mein. Safety > hard timing > buffered I/O.

Level 5 — Mastery

L5.1 — Full latency + throughput audit

Problem. Ek Cortex-M4 MHz par. Deterministic hardware entry cycles. Worst same-or-higher blocking ek critical section hai jo IRQs cycles ke liye mask karta hai. ISR body khud cycles chalti hai. (a) Worst-case latency (event → first ISR instruction) ns mein. (b) Total time CPU lower-priority interrupts ke liye unavailable hai is ISR ki wajah se (entry + body + exit unstack cycles), ns mein. (c) Ek event source har µs mein fire karta hai. Kya system keep up kar sakta hai? Kitne margin se?

Recall Solution (L5.1)

s ns.

(a) . kyun? Hardware entry tab tak shuru nahi ho sakti jab tak -cycle mask lift na ho jaaye; sequential hai, toh add karo.

(b) cycles µs. Teeno kyun sum karte hain? Jis moment hardware entry shuru hoti hai us moment se jab tak ISR fully return kar le, CPU is ISR chal raha hai aur koi lower-priority cheez start nahi ho sakti — toh blocking window jo ek lower-priority interrupt dekhta hai poora contiguous span hai: -cycle entry (stacking + vector fetch), phir -cycle body, phir -cycle exit (unstacking). Ye back-to-back hote hain koi gap nahi, toh teeno add karte hain; koi overlap subtract karne ke liye nahi hai.

(c) Pehle poora firing-to-done span compute karo — event fire hone se lekar ISR completely finish hone tak — kyunki wahi total work hai jo ek event generate karta hai. Ye blocked mask plus busy window hai: µs. µs se compare kyun karte hain? Agar ek event ka total work ( µs) agla event aane ( µs baad) se pehle khatam ho jaaye, toh system kabhi peeche nahi padta — har event fully service hota hai time bacha ke. Kyunki , ye keep up karta hai. Margin µs idle time per period. Busy fraction , main loop aur baaki IRQs ke liye headroom bacha ke. Headroom kyun matter karta hai: agar busy fraction ke qareeb jaata, toh baaki sab ke liye koi cycles nahi bachte aur deadlines slip karne lagti.

L5.2 — Frozen loop debug karo

Problem. Ye code forever spin karta hai even though ek ISR done = 1 set karta hai. Bug aur fix explain karo, is terms mein ki compiler ne kya kiya.

int done = 0;
// ISR: done = 1;
while (!done) { /* wait */ }
Recall Solution (L5.2)

Bug: done volatile nahi hai. Optimizing compiler dekhta hai ki while loop kabhi done change nahi karta, toh wo done ko RAM se ek register mein ek baar padhta hai, phir cached register value par forever loop karta hai. Ise koi knowledge nahi hai ki ek asynchronous ISR RAM likhta hai. Fix: volatile int done = 0;. Ye kaise kaam karta hai: volatile compiler ko force karta hai ki done ko memory se har loop iteration par re-read kare, toh wo eventually ISR ki write dekh leta hai. Ye classic ISR↔main shared-variable hazard hai. Multi-byte shared data ke liye tum bhi atomic access chahte ho (read/write ke around IRQs mask karo) taaki tum kabhi half-updated value na dekho.


Recall Quick self-test

Lower priority number matlab ::: zyada urgent (0 sabse top hai). Sub-priority ek running equal-preemption ISR ko preempt kar sakta hai? ::: Nahi — ye sirf pending ties break karta hai. ISR ko apna flag early clear kyun karna chahiye? ::: Warna ye forever re-enter ho sakta hai. ISR-shared variables volatile kyun hone chahiye? ::: Taaki compiler unhe register mein cache karne ki bajaye memory se re-read kare. Worst-case latency blocked time aur hardware entry add karta hai — max ya sum? ::: Sum (ye sequential hain).