FreeRTOS IPC — queues, semaphores, mutexes, event groups

5.5.11 · Coding › Embedded Systems & Real-Time Software

IPC exist kyon karta hai bilkul?

Saare IPC ke do kaam:

Synchronization — "wait karo jab tak X nahi hota" (semaphore, event group).
Mutual exclusion + data transfer — "ek time par sirf ek hi" / "ek value safely hand over karo" (mutex, queue).

Queues — foundation

Kernel ise implement kaise karta hai (mental model):

Ek queue length × itemSize bytes ke liye storage rakhta hai saath mein blocked tasks ki do lists: tasks waiting to send aur tasks waiting to receive.
Khaali queue par Receive: caller ko timeout ke saath "waiting to receive" list mein move kar diya jata hai. Jab Send aata hai, kernel item copy karta hai aur highest-priority waiting receiver ko unblock karta hai.

Worked example Producer/consumer

QueueHandle_t q = xQueueCreate(5, sizeof(uint32_t)); // 5 slots
// Producer task
uint32_t v = read_sensor();
xQueueSend(q, &v, pdMS_TO_TICKS(10)); // block ≤10 ms if full
// Consumer task
uint32_t got;
if (xQueueReceive(q, &got, portMAX_DELAY)) use(got); // block forever

&v kyon? Send/Receive ek pointer to the item to copy lete hain, item khud nahi. portMAX_DELAY kyon? Consumer ke paas karne ko kuch nahi jab tak data exist nahi karta — kernel ko use sone do.

Semaphores — counting tickets

Worked example ISR → task signaling (the classic)

// ISR (e.g. UART byte ready)
BaseType_t woke = pdFALSE;
xSemaphoreGiveFromISR(sem, &woke);
portYIELD_FROM_ISR(woke);          // switch to woken task on ISR exit
// Task
for(;;){ xSemaphoreTake(sem, portMAX_DELAY); handle_data(); }

ISR mein give kyon, ISR mein handle kyon nahi? ISRs short hone chahiye; bhaari kaam ek task par defer karo ("deferred interrupt processing"). Semaphore wake-up signal hai. portYIELD_FROM_ISR kyon? Agar woken task higher priority ka hai, toh next tick ka wait karne ki jagah exit par immediately switch karo — lower latency.

Mutexes — exclusive keys with priority inheritance

Priority inversion (BAD)            With inheritance (GOOD)
H ──wants lock──▒▒▒ blocked         H ──wants──▒ short block
M ════runs forever════              L boosted to H, finishes lock
L holds lock, starved               M can't preempt boosted L

Figure — FreeRTOS IPC — queues, semaphores, mutexes, event groups

Worked example Shared bus protect karna

SemaphoreHandle_t m = xSemaphoreCreateMutex();
xSemaphoreTake(m, portMAX_DELAY);   // acquire key
i2c_write(...);                     // critical section
xSemaphoreGiveBack:                 
xSemaphoreGive(m);                  // release key

Same task ko kyon dena chahiye? Ownership hi priority inheritance ko possible banata hai aur accidental release rokhta hai. Mutex kabhi ISR signaling ke liye mat use karo (ISRs ka koi task identity nahi hota own/inherit karne ke liye).

Event Groups — bits ke combinations par wait karna

Worked example Do conditions ka wait karna

#define WIFI_BIT (1<<0)
#define CFG_BIT  (1<<1)
EventBits_t b = xEventGroupWaitBits(
    eg, WIFI_BIT|CFG_BIT,
    pdTRUE,   // clear bits on exit
    pdTRUE,   // wait for ALL (AND)
    portMAX_DELAY);
// reaches here only when BOTH bits were set

Clear ke liye pdTRUE kyon? Taki next cycle fresh start kare aur hum stale bits par re-trigger na hon.

Sahi tool choose karna (the 80/20 core)

Zaroorat	Use karo	Key reason
Task→task data pass karna	Queue	value copy karta hai, FIFO, blocking
ISR kisi task ko signal karta hai	Binary semaphore	lightweight wake-up
N resources/events count karna	Counting semaphore	yaad rakhta hai kitne hain
Shared resource protect karna	Mutex	ownership + priority inheritance
AND/OR conditions par wait karna	Event group	combine + broadcast

Common mistake Steel-manned traps

"Main ISR se mutex use karunga task signal karne ke liye — ye sirf ek binary semaphore hai." Kyun sahi lagta hai: mutex hai binary, ISRs tasks ko signal karte hain. Kyun galat hai: ek ISR ka koi task context nahi hai, isliye record karne ke liye koi owner nahi aur priority inheritance meaningless/undefined hai; ownership rules ek ISR ko use give karne se rokti hain. Fix: binary/counting semaphore (...FromISR) se signal karo, mutexes sirf task-to-task locking ke liye use karo.

"Copying avoid karne ke liye queue se pointer bhejo." Kyun sahi lagta hai: bade buffers copy karne se bachata hai, faster. Kyun risky hai: queue pointer copy karta hai, data nahi; agar buffer receiver ke read karne se pehle free/overwrite ho jaye → dangling pointer. Fix: ownership explicitly transfer karo (allocate karo, pointer bhejo, receiver free kare) ya chhoti items ke liye value se copy karo.

"ISR se blocking API (xQueueReceive with timeout) call karna." Kyun sahi lagta hai: same function name. Fix: ISRs kabhi block nahi karna chahiye — ...FromISR variants use karo (no blocking, return pdFALSE if can't act) aur portYIELD_FROM_ISR.

Recall Feynman: 12-saal ke bachche ko explain karo

Socho ek teacher (CPU) kaafi bacchon (tasks) ki ek ek karke help karta hai. Queue notes ki ek tray hai — ek bachcha note dalta hai, doosra baad mein uthata hai, order mein. Semaphore tokens ki ek jar hai: slide use karne ke liye token lo; agar jar khaali hai toh baitho aur wait karo jab tak koi token daale. Mutex single bathroom key hai — sirf woh bachcha jo use le gaya wahi wapas de sakta hai, aur agar ek slow bachche ke paas key hai jab ek important bachcha tadap raha hai, teacher slow bachche ko kehta hai "jaldi karo, pehle jao" taki key jaldi wapas aaye. Event group wall par ek checklist hai — ek bachcha wait karta hai jab tak dono "lunch ready" aur "haath dhule" tick nahi ho jaate phir khane jaata hai.

Flashcards

FreeRTOS queue kisse transfer karta hai — value se ya reference se?

Value se (item ke bytes ko kernel storage mein copy karta hai), jab tak aap deliberately pointer nahi bhejte.

Binary semaphore vs counting semaphore?

Binary: count 0/1 (ek event flag). Counting: 0..N, yaad rakhta hai kitne events/resources available hain.

Ek semaphore internally kaunsi queue ke equivalent hai?

ItemSize = 0 wali queue; count zero-byte items ki sankhya hai jo present hain.

Locking ke liye binary semaphore ki jagah mutex kyon use karte hain?

Mutex ka ek owner hota hai (sirf lene wala de sakta hai) aur priority inversion se bachne ke liye priority inheritance support karta hai.

Priority inversion kya hai aur mutex ise kaise fix karta hai?

Lock hold karne wala low-priority task high-priority task ko block karta hai jab medium task low task ko starve karta hai; mutex holder ki priority waiter tak boost kar deta hai release hone tak.

ISR se mutex kyon use NAHI karna chahiye?

ISR ka koi task identity nahi hota mutex own karne ya priority inherit karne ke liye; binary/counting semaphore ka FromISR variant use karo.

Kaun sa IPC ek task ko ALL ya ANY kai conditions ka wait karne deta hai?

Event group (bits AND/OR wait ke saath, optional clear-on-exit).

ISR mein xSemaphoreGiveFromISR + portYIELD_FROM_ISR kyon call karte hain?

Give waiting task ko block kiye bina signal karta hai; yield agar woh higher priority ka hai toh immediately use switch karta hai, latency kam karta hai.

Kya hota hai jab ek task portMAX_DELAY ke saath khaali queue par xQueueReceive karta hai?

Ye block ho jaata hai (ready list se hata diya jaata hai) jab tak koi item send nahi hota, tab kernel item copy karta hai aur use unblock karta hai — CPU meanwhile free rehta hai.

Queue se pointer bhejna ka risk kya hai?

Dangling pointer agar pointed-to data receiver ke read karne se pehle free/overwrite ho jaye; ownership explicitly manage karna padta hai.

Connections

RTOS Scheduling — preemption & priorities (race conditions kyon hoti hain)
Priority Inversion & the Mars Pathfinder bug (real-world mutex motivation)
Interrupt Service Routines & Deferred Processing (semaphore-from-ISR pattern)
Critical Sections & taskENTER_CRITICAL (alternative short-term mutual exclusion)
Producer–Consumer Pattern (queue archetype)
Memory Management in FreeRTOS — heap_1..5 (kernel objects kahan rehte hain)