FreeRTOS — task creation, priorities, xTaskCreate: Visual walkthrough

5.5.10 · D2 · Coding › Embedded Systems & Real-Time Software › FreeRTOS — task creation, priorities, xTaskCreate

Yahan sab kuch parent note FreeRTOS — Task Creation, Priorities, xTaskCreate ko refine karta hai. Hum assume karte hain ki tum sirf itna jaante ho ki "ek CPU ek waqt mein ek instruction run karta hai."

Step 1 — Ek CPU, time ki ek lane

KYA: hum time ko ek lane ki tarah draw karte hain aur mark karte hain ki ek waqt mein sirf ek box us mein baith sakta hai.

KYU: scheduler ka poora reason yahi hai ki demand (bahut saare tasks run karna chahte hain) supply se zyada hai (ek lane). Agar infinite lanes hoti, toh kisi scheduler ki zaroorat nahi hoti. Yeh picture apne dimaag mein fix karna #1 beginner error se bachata hai: tasks ko "parallel" mein run hota imagine karna.

PICTURE: lane wo white bar hai. Uske andar baitha coloured block woh task hai jo Running hai. Baaki sab lane ke upar stack hoke wait kar rahe hain.

Figure — FreeRTOS — task creation, priorities, xTaskCreate

Step 2 — Har task ke paas do numbers hote hain jo matter karte hain

Symbols ko aise padhte hain:

$priority number P \in {0, 1, \dots, the top slot C - 1}, idle task lives here P = 0$

$P$ — urgency dial. Bada $P$ = zyada urgent. (Yeh FreeRTOS convention hai; parent note ki steel-manned mistake #1 dekho.)
$C$ — tune compile ki hui total priority levels ki count. Highest usable number $C - 1$ hai, $C$ nahi, kyunki hum $0$ se count shuru karte hain.
$P = 0$ — idle task ka reserved ghar; koi useful task ise share nahi karna chahiye.

KYA: hum har waiting task ko uske number $P$ aur state $S$ se tag karte hain.

KYU: scheduler tumhare code ke baare mein stateless hai — use nahi pata ki readSensor() kya karta hai. Woh sirf tasks ko in do numbers se sort karta hai. Toh yahi woh levers hain jo tum actually control karte ho.

PICTURE: ab har waiting box ek number badge $P$ pahne hue hai aur ek colour hai jo uski state batata hai.

Step 3 — Jo run nahi kar sakte unhe hatao

Hum ready set define karte hain — sirf woh tasks jo CPU jeetne ke eligible hain:

$R = {t : S (t) = Ready or Running}$

$R$ — ready set, hamaari shortlist of candidates.
$t$ — ek task.
$S (t)$ — us task ki state. Sirf Ready/Running tasks filter pass karte hain.

KYA: hum Blocked/Suspended boxes ko grey karke hatate hain, ek shortlist $R$ bachti hai.

KYU: sab tasks mein se chunna galat hoga — tum CPU kisi aisi cheez ko de rahe ho jo sensor ka wait kar ke so rahi hai. Pehle filter karna hi blocking ko free banata hai (woh vTaskDelay mechanism bilkul isi par rely karta hai).

PICTURE: faded boxes = race se bahar; solid boxes = shortlist $R$ .

Step 4 — Ek rule: ready set mein maximum priority wala task chuno

$P^{⋆}$ — winning priority level, shortlist mein sabse bada badge.
$max_{t \in R}$ — "ready set scan karo, sabse bada rakho." max kyun, min kyun nahi? Kyunki FreeRTOS mein bada = zyada urgent. Agar FreeRTOS UNIX "nice" convention use karta toh yahan min hota — operator literally convention ko encode karta hai.
$P (t)$ — candidate $t$ ki priority.

KYA: solid boxes mein se hum sabse bade number wale ko crown karte hain.

KYU: yeh ek line hi hai preemptive priority scheduling. Baaki sab kuch (preemption, starvation, round-robin) is rule ko baar baar apply karne ka consequence hai jab states change hoti hain.

PICTURE: ek arrow highest-badge box ko time lane mein drop karta hai; baaki wait karte rehte hain.

Step 5 — Preemption: $R$ change hote hi rule dobara run karo

Parent ke Worked Example 2 ko consider karo: vLow at $P = 1$ (kabhi block nahi hota) aur vHigh at $P = 3$ .

$while v H i g h Blocked: R = {v L o w}, P^{⋆} = 1 \Rightarrow v L o w runs$ $at wake-up: R = {v L o w, v H i g h}, P^{⋆} = 3 \Rightarrow v H i g h preempts$

Set $R$ us moment badi ho gayi jab vHigh ki 10 ms delay expire hui.
$P^{⋆}$ $1 \to 3$ jump kar gaya, toh winner badal gaya, toh lane ka occupant forcibly swap ho gaya. Us swap ki mechanics (registers ko TCB mein save karna) Context Switching mein cover hai.

KYA: hum lane ka occupant vLow se vHigh mein exactly wake-up instant par flip hota dikhate hain, phir wapas flip hota hai.

KYU: yahi reason hai ki ek real-time sensor read ko deterministic timing milti hai tab bhi jab ek low task math roke hue hai — rule dobara fire hota hai aur high task har baar line cut kar leta hai.

PICTURE: ek timeline jahan blue vLow block ko yellow vHigh block har 10 ms par kaat ke ghus jaata hai.

Step 6 — Tie case: equal priority ⇒ round-robin

$Tie: {t : P (t) = P^{⋆}} = {t_{1}, t_{2}} \Rightarrow t_{1} \to t_{2} \to t_{1} \to \dots (one tick each)$

Braced set matlab "top level match karne wale sare candidates."
Cycle $t_{1} \to t_{2} \to t_{1}$ round-robin hai — fair sharing, sirf tab active jab configUSE_TIME_SLICING = 1. Round-robin vs Preemptive Scheduling dekho.

KYA: do same-colour boxes ek-ek tick karke lane bharte hain.

KYU: tie-breaker ke bina priorities collide hone par scheduler undefined ho jaata. Round-robin equal priority ko equal share banata hai, jo exactly "do LEDs ek saath blink karna" ke liye chahiye.

PICTURE: lane L1, L2, L1, L2 tick-wide slices mein alternate karta hai.

Step 7 — Degenerate case: koi Ready nahi hai

$R \supseteq {idle} always \Rightarrow P^{⋆} \geq 0 is always defined$

$R \supseteq {idle}$ — ready set mein hamesha kam se kam idle task rehta hai.
Isliye $max$ kabhi empty set par nahi liya jaata; $P = 0$ par ek floor hamesha hota hai.

KYA: jab sare coloured boxes Blocked ho ke fade ho jaate hain, grey idle box lane mein drop ho jaata hai.

KYU: isliye ek high-priority task jo kabhi block nahi hota catastrophic hota hai (parent mistake #3): woh $P^{⋆}$ hamesha ke liye hold karta hai, idle task kabhi run nahi hota, toh power-saving aur watchdog feed jo idle mein rehte hain woh kabhi nahi hoti. Degenerate case sikhata hai ki hamesha block karo.

PICTURE: sare user boxes greyed aur blocked; lane mein sirf akela idle task hai.

Ek-picture summary

FreeRTOS ka har scheduling decision yahi loop hai: Ready tak filter karo → max priority lo → ties ko round-robin se todo → har event par dobara run karo, idle ko floor ke roop mein rakh ke.

Recall Feynman retelling — poora walkthrough simple shabdon mein

Ek cook hai aur ek cutting board hai (Step 1: ek CPU, ek time lane). Har recipe card par ek urgency number aur ek status flag hai (Step 2). Choose karne se pehle, manager har woh card phek deta hai jis par "oven ka wait kar raha hai" likha ho — woh cooks so rahe hain aur count nahi karte (Step 3). Jo bacha usmein se, woh sabse bade urgency number wala card uthata hai aur us cook ko board par rakhta hai (Step 4: $P^{⋆} = max$ ). Jaise hi kisi soye hue cook ki timer ding karti hai, manager dobara check karta hai; agar naya jaaga cook zyada urgent hai, toh woh current cook ko mid-chop pe hataata hai (Step 5: preemption). Agar do cards top number ke liye tie karte hain, toh woh baar baar turn lete hain, kuch seconds har baar (Step 6: round-robin). Aur agar sab real cooks so rahe hain, toh ek lazy backup cook hai jo board par hi so jaata hai taaki woh kabhi khali na rahe (Step 7: idle at priority 0). Yeh poori story har ding par dobara chalti hai — yahi poora scheduler hai.

Recall Self-test

Scheduling operator max kyun hai aur min kyun nahi? ::: Kyunki FreeRTOS define karta hai ki bada priority number = zyada urgent, isliye sabse bada ready priority jeet ta hai. Ek task vTaskDelay par Blocked hai — kya woh ready set R mein hai? ::: Nahi; sirf Ready/Running tasks R mein hote hain, isliye jab tak uski delay expire nahi hoti use choose nahi kiya ja sakta. Do tasks top priority P-star share karte hain — kya hota hai? ::: Round-robin time-slicing, ek-ek tick each (agar configUSE_TIME_SLICING=1 ho). R kabhi empty kyun nahi ho sakta? ::: Priority 0 par idle task hamesha Ready rehta hai, isliye max hamesha defined hota hai. P-star ki re-evaluation kya trigger karta hai? ::: Koi bhi event jo R ko change kare — delay ka wake hona, queue/semaphore signal, ya interrupt.