Ce este un RTOS?
Un RTOS (Real-Time Operating System) e un sistem de operare specializat pentru aplicații cu constrângeri temporale. Diferența fundamentală față de un SO general (Linux, Windows): predictibilitatea e mai importantă decât viteza medie.
Un RTOS garantează că un task va răspunde la un eveniment într-un interval de timp cunoscut — nu doar "de obicei", ci întotdeauna.
Timp real: hard vs soft
| Tip | Consecința depășirii termenului | Exemple | |---|---|---| | Hard real-time | Catastrofă (pierdere de vieți, daune materiale) | Airbag, frânare ABS, control reactoare | | Soft real-time | Degradare a calității, dar fără catastrofă | Streaming audio/video, jocuri | | Firm real-time | Rezultatul e inutil după termen, dar nu catastrofal | Senzor GPS, citire RFID |
Exemple de constrângeri
| Sistem | Latență maximă admisă | Consecința depășirii | |---|---|---| | Airbag auto | ~5 ms | Moarte | | Frânare ABS | ~10 ms | Pierdere control vehicul | | Control motor avion | ~50 ms | Prăbușire | | Satelit | ~100 ms | Pierdere orbită / date | | Router | ~1 ms | Pierdere pachete | | Sistem audio | ~20 ms | Clip-uri, distorsiuni |
Cum e diferit un RTOS de un SO general
1. Scheduler — inima RTOS-ului
Un SO general (Linux, Windows) folosește CFS (Completely Fair Scheduler) sau round-robin — scopul e să distribuie corect timpul de CPU între toate procesele.
Un RTOS folosește scheduling preemptiv bazat pe prioritate — task-ul cu cea mai mare prioritate gata de execuție rulează imediat, indiferent de ceilalți.
SO general: A → B → C → A → B → C → (fairness)
RTOS: C(high prio) → A(low) → C → B(mid) → C → (priorities)
2. Latența întreruperilor
Timpul dintre momentul în care o întrerupere hardware apare și momentul în care handler-ul ei începe să execute cod.
- Linux standard: 10-100 µs (poate varia)
- Linux RT (PREEMPT_RT): ~5-15 µs
- RTOS tipic: < 1 µs (determinist)
3. Gestionarea memoriei
SO-urile generale folosesc memorie virtuală cu paginare — pot apărea page fault-uri, swapping, și întârzieri impredictibile.
RTOS-urile evită memoria virtuală. Alocarea e de obicei statică (la compilare) sau din pool-uri fixe. Nu există swapping, nu există page fault-uri.
4. Dimensiune
- Linux: 5-50 MB nucleu, necesită MMU
- RTOS tipic: 5-500 KB, poate rula fără MMU
Arhitectura unui RTOS
┌────────────────────────────────────────┐
│ Aplicații utilizator │
├────────────────────────────────────────┤
│ API (POSIX / nativ) │
├────────────┬───────────┬───────────────┤
│ Scheduler │ IPC │ Memory mgmt │
├────────────┼───────────┼───────────────┤
│ Timere │ ISR │ Device I/O │
├────────────┴───────────┴───────────────┤
│ HAL / BSP │
├────────────────────────────────────────┤
│ Hardware │
└────────────────────────────────────────┘
Componente esențiale
| Componentă | Rol | |---|---| | Scheduler | Decide ce task rulează, când și pentru cât timp | | IPC | Mesaje, semafoare, evenimente, pipe-uri | | Memory Manager | Pool-uri fixe, regiuni, partiții | | Timer | Tick de sistem, watchdog, temporizatoare | | ISR Handler | Întreruperi hardware cu latență minimă | | BSP/ HAL | Stratul de abstractizare hardware |
Scheduling în RTOS
Rate Monotonic (RMS)
Task-urile periodice au prioritate invers proporțională cu perioada: cu cât perioada e mai scurtă, cu atât prioritatea e mai mare.
Suficiență: Un set de n task-uri RMS e schedulabil dacă:
U = ∑ᵢ Cᵢ/Tᵢ ≤ n(2^{1/n} − 1)
Pentru n → ∞, limita e ln 2 ≈ 0.693.
Earliest Deadline First (EDF)
Task-ul cu termenul limită cel mai apropiat rulează primul. EDF optimizează utilizarea CPU-ului (poate ajunge la 100%), dar e mai complex și mai puțin predictibil în caz de suprasarcină.
Priority Inheritance Protocol
Previne inversarea priorității — un task cu prioritate înaltă blocat de un task cu prioritate joasă care deține un mutex. Task-ul cu prioritate joasă „moștenește" temporar prioritatea înaltă până când eliberează mutex-ul.
Problema inversării priorității
Timp →
Task H (prioritate înaltă): ████░░░░░░░░████
Task M (prioritate medie): ░░░░████░░░░░░░░
Task L (prioritate joasă): ░░████░░░░░░░░░░
↑ L deține mutex-ul
↑ H așteaptă mutex-ul lui L
↑ M preemptează L (care are mutex-ul!)
Fără moștenire: Task L (care deține mutex-ul cerut de H) e preemptat de M → H așteaptă ca L să continue, dar L nu poate pentru că M rulează. H moare de foame din cauza lui M, nu a lui L.
Soluția: L moștenește prioritatea lui H cât timp deține mutex-ul, blocând indirect și preemptarea de către M.
RTOS-uri populare
| Nume | Licență | Arhitecturi | Aplicații tipice | |---|---|---|---| | FreeRTOS | MIT (gratis) | ARM, AVR, RISC-V | IoT, embedded mic | | Zephyr | Apache 2.0 | ARM, x86, RISC-V | IoT, wearable | | RTEMS | BSD | ARM, SPARC, PowerPC | Aerospațial, militar | | VxWorks | Proprietar | ARM, x86, PowerPC | Avioane F-35, F-16, rover-e | | INTEGRITY | Proprietar | ARM, x86 | Avionică, medical | | ThreadX | Proprietar | ARM, RISC-V | IoT, automotive | | MQX | Proprietar | ARM, ColdFire | Industrial, medical | | NuttX | BSD | ARM, x86, RISC-V | Drone, IoT |
FreeRTOS
Cel mai popular RTOS open-source. A început ca un proiect mic în 2003 și acum e standard în embedded. Foarte ușor de portat pe orice arhitectură.
pseudocod — task FreeRTOS:
void task_senzor(void *params):
while true:
valoare = citeste_senzor()
if valoare > prag:
trimite_alerta(queue, valoare)
vTaskDelay(10 ms) // 100 Hz
VxWorks
Standardul militar. Folosit în F-16, F-35, Patriot, drone, și rover-e NASA. Certificat DO-178B. Suportă SMP, protecție de memorie, și networking complet.
Zephyr
RTOS modern de la Linux Foundation. Suportă Bluetooth 5.x, WiFi, USB, și TF-M pentru securitate. Scris în C, cu build system bazat on CMake.
Comparație RTOS vs Linux RT
| Caracteristică | RTOS tipic | Linux + PREEMPT_RT | |---|---|---| | Latență ISR | < 1 µs | 5-15 µs | | Scheduling | Prioritate preemptivă | Prioritate preemptivă + CFS | | Memorie | Statică, pool-uri | Virtuală, paginare | | Dimensiune nucleu | 10-500 KB | 5-50 MB | | MMU necesară | Nu | Da | | Suport drivere | Manual, BSP-specific | Generic, vast | | POSIX | Parțial | Complet | | Cost | Gratis sau $10k+ | Gratis |
Când alegi un RTOS în loc de Linux
Alegi RTOS când:
- Latența maximă admisă e sub 50 µs
- Resursele hardware sunt limitate (sub 1 MB RAM, fără MMU)
- Sistemul trebuie certificat (DO-178C, IEC 61508, ISO 26262)
- Predictibilitatea e mai importantă decât funcțiile
Alegi Linux când:
- Ai nevoie de networking complex (TCP/IP stack complet, TLS)
- Ai nevoie de drivere pentru dispozitive standard (USB, WiFi, GPU)
- Ai memorie suficientă (peste 64 MB RAM)
- Productivitatea de dezvoltare e mai importantă decât latența
Concluzie
Un RTOS nu e un Linux mai mic — e un sistem fundamental diferit, optimizat pentru predictibilitate și determinism. Înțelegerea scheduler-elor, a inversării priorității și a constrângerilor temporale e esențială pentru orice inginer care lucrează cu sisteme embedded critice.