FreeRTOS vs Zephyr vs ThreadX: quale RTOS scegliere

Introduzione

Scegliere il giusto RTOS è una decisione architetturale che incide direttamente su prestazioni, time-to-market, sicurezza, manutenzione e possibilità di evoluzione del prodotto. Nel mondo embedded, FreeRTOS, Zephyr e ThreadX rappresentano oggi tre delle opzioni più rilevanti per realizzare sistemi real-time su microcontrollori e piattaforme connesse.

Ognuno di questi RTOS risponde a esigenze diverse. FreeRTOS resta una scelta molto diffusa per sistemi semplici, compatti e orientati all’integrazione con ecosistemi vendor o cloud. Zephyr si distingue per approccio modulare, governance open e forte attenzione a sicurezza, toolchain unificata e connettività moderna. ThreadX, oggi evoluto nel progetto Eclipse ThreadX, continua a essere apprezzato per il determinismo, la maturità industriale e la disponibilità di componenti middleware consolidati.

In questo confronto analizziamo le differenze più importanti tra FreeRTOS, Zephyr e ThreadX: footprint, modello di sviluppo, licensing, sicurezza, networking, toolchain e casi d’uso. L’obiettivo non è individuare un vincitore assoluto, ma capire quale RTOS possa essere la scelta più adatta in base ai vincoli reali del progetto.

Licenza, governance e continuità del progetto

Quando si valuta un RTOS, non bisogna fermarsi alle sole API o alle prestazioni del kernel. Anche il modello di governance, la licenza e la solidità dell’ecosistema incidono sulla sostenibilità del progetto nel lungo periodo.

FreeRTOS è distribuito con licenza MIT, una delle più semplici e permissive da gestire in contesti commerciali. Questo ne facilita l’adozione in prodotti embedded, sia in ambito industriale sia in progetti con forte attenzione al time-to-market. La documentazione è ampia e l’integrazione nei principali ecosistemi hardware contribuisce alla sua diffusione.

Zephyr è un progetto sostenuto dalla Linux Foundation e sviluppato con un modello aperto, collaborativo e vendor-neutral. La disponibilità di release LTS, la gestione pubblica delle issue e l’attenzione alla supply-chain security rendono Zephyr particolarmente interessante per aziende che vogliono visibilità sul ciclo di vita del software e maggiore tracciabilità tecnica.

ThreadX, dopo il passaggio da Azure RTOS a Eclipse ThreadX, ha consolidato una governance più aperta pur mantenendo il posizionamento da RTOS maturo e orientato a contesti professionali. La presenza storica di middleware come NetX Duo, FileX, USBX e GUIX continua a renderlo una scelta rilevante per progetti industriali e regolamentati.

Footprint, concorrenza e determinismo

Uno dei primi criteri di scelta di un RTOS è la sua capacità di adattarsi ai vincoli dell’hardware. In sistemi basati su microcontrollori entry-level, dove RAM e flash sono limitate, il footprint del kernel e la prevedibilità temporale diventano fattori decisivi.

FreeRTOS resta spesso la scelta più naturale quando si cerca un kernel compatto, semplice da comprendere e con primitive essenziali per task scheduling, code, semafori e sincronizzazione. Questo approccio riduce la complessità iniziale e si adatta bene a prodotti embedded con requisiti chiari e una struttura software relativamente controllata.

Zephyr propone un’architettura più modulare. Il kernel può essere configurato con diversi sottosistemi opzionali, consentendo di scalare da applicazioni IoT relativamente leggere fino a sistemi più complessi con networking, file system, Bluetooth o stack aggiuntivi. Questa flessibilità è un vantaggio, ma richiede anche maggiore disciplina nella configurazione e nel controllo delle dipendenze.

ThreadX è tradizionalmente apprezzato per il suo comportamento deterministico e per la maturità raggiunta in contesti industriali. La sua adozione storica in sistemi professionali lo rende una scelta interessante quando servono latenze prevedibili, integrazione stretta con middleware dedicati e un comportamento ben conosciuto lungo l’intero ciclo di vita del prodotto.

Un tema architetturale interessante emerso anche nella letteratura recente è il cosiddetto Diminishing Bandwidth Problem, legato al costo crescente delle sezioni critiche e delle strutture interne usate dal kernel per gestire task e sincronizzazione. In diversi RTOS tradizionali, alcune operazioni sulle liste di scheduling o di attesa possono estendersi in funzione del numero di task, con possibili effetti sulla latenza e sulla banda effettivamente disponibile per la gestione di eventi ad alta frequenza.

Nella pratica embedded su microcontrollore, questo problema viene spesso mitigato con un buon uso di DMA, FIFO hardware, interrupt ben progettati e meccanismi di deferred work. Nei contesti più critici, invece, la scelta dell’RTOS deve essere accompagnata da un’analisi più rigorosa del comportamento temporale, soprattutto se il sistema opera vicino ai limiti della piattaforma.

Toolchain e developer experience

L’esperienza di sviluppo conta quanto il kernel. Un RTOS non viene scelto solo per il comportamento run-time, ma anche per la qualità del flusso di build, della configurazione, del debug e dell’integrazione nel processo di sviluppo del team.

FreeRTOS si inserisce molto bene nei flussi imposti dai vendor. Spesso è disponibile direttamente negli SDK e negli IDE ufficiali delle piattaforme, come avviene in molti ambienti STM32, ESP32 o NXP. Questo riduce la barriera d’ingresso, ma rende anche l’esperienza più dipendente dal produttore della MCU e meno uniforme tra una piattaforma e l’altra.

Zephyr punta invece a un flusso più coerente e centralizzato, basato su CMake, Kconfig e Devicetree. Questo modello è particolarmente utile nei progetti multi-board, nelle CI/CD e nei prodotti che devono essere mantenuti su famiglie hardware diverse con una struttura comune. Il vantaggio è una maggiore uniformità; il rovescio della medaglia è una curva iniziale più ripida per chi proviene da ambienti embedded più tradizionali.

ThreadX offre un ecosistema più classico, con una documentazione storicamente solida e una suite di componenti integrati che agevolano la costruzione di sistemi completi. Il passaggio a Eclipse ha migliorato la visibilità del codice e delle issue, favorendo processi di audit, integrazione e collaborazione più moderni rispetto al passato.

Networking, IoT e protocolli supportati

Nei sistemi embedded moderni la scelta dell’RTOS è spesso influenzata dalla connettività. Se il prodotto deve supportare Ethernet, Wi-Fi, BLE, Thread, Matter o protocolli cloud, il kernel da solo non basta: diventa fondamentale valutare la maturità degli stack disponibili e la qualità dell’integrazione.

FreeRTOS è molto diffuso nei prodotti IoT compatti, anche grazie alla disponibilità di librerie dedicate a MQTT, TLS, OTA e integrazione con l’ecosistema AWS. Questo lo rende adatto a dispositivi connessi che vogliono ridurre la complessità d’integrazione e accelerare lo sviluppo.

Zephyr è particolarmente interessante quando la connettività è una parte centrale del prodotto. Il supporto a OpenThread, Bluetooth, Matter e altri sottosistemi di rete lo rende una scelta molto forte per smart home, automazione, edge node e dispositivi interoperabili in ecosistemi moderni.

ThreadX, grazie a NetX Duo, offre uno stack di rete consolidato per IPv4 e IPv6 ed è spesso considerato in applicazioni dove networking e prevedibilità temporale devono convivere in un ambiente software controllato. In questi casi, la disponibilità di middleware integrato può ridurre tempi e rischi di integrazione.

Sicurezza, aggiornabilità e compliance

La sicurezza è oggi uno dei criteri più importanti nella scelta di un RTOS. Non si tratta solo di avere una libreria TLS o un modulo OTA, ma di valutare processi di gestione delle vulnerabilità, tracciabilità delle dipendenze, aggiornabilità e capacità di sostenere audit tecnici nel tempo.

FreeRTOS adotta un approccio pragmatico e modulare: il kernel può essere affiancato da componenti per sicurezza, comunicazione e aggiornamento remoto in funzione del caso d’uso. Questo consente di contenere il footprint quando necessario, ma richiede attenzione nella composizione dell’intero stack.

Zephyr si distingue per un lavoro più esplicito su sicurezza by design e supply-chain security. La presenza di processi CVE, gestione delle vulnerabilità, SBOM e release strutturate è un punto molto forte per chi deve affrontare compliance, audit o requisiti di tracciabilità più severi.

ThreadX mantiene un posizionamento credibile nei contesti regolamentati, anche grazie alla sua storia in domini dove determinismo, robustezza e validazione del middleware sono aspetti centrali. Quando il progetto si muove in settori safety-critical o vicino a percorsi certificativi, questa continuità industriale resta un elemento da considerare con attenzione.

Ecosistema, maturità e prospettive

Guardando al 2025, i tre RTOS continuano a occupare spazi ben distinti ma spesso sovrapposti. FreeRTOS resta il riferimento più diffuso per moltissimi progetti MCU-oriented, grazie a semplicità, licenza permissiva e forte presenza negli SDK dei produttori.

Zephyr continua a crescere come piattaforma embedded moderna, soprattutto nei contesti dove contano modularità, connettività avanzata, governance aperta e una toolchain coerente. La sua evoluzione lo rende particolarmente interessante per progetti che vogliono costruire una base software riutilizzabile e strutturata nel lungo periodo.

ThreadX conserva un valore elevato nei domini industriali dove maturità, prevedibilità e disponibilità di middleware integrati contano più della sola popolarità. Il passaggio sotto Eclipse rafforza inoltre la leggibilità del progetto e la sua collocazione in un ecosistema più aperto.

Tabella di sintesi

Conclusioni

Nel 2025 non esiste un RTOS migliore in assoluto, ma esiste quello più adatto al contesto del progetto. FreeRTOS resta una scelta molto efficace quando contano semplicità, footprint contenuto, rapidità di adozione e integrazione con ecosistemi consolidati. Zephyr è particolarmente convincente quando servono modularità, connettività avanzata, governance aperta e una base software più strutturata nel lungo periodo. ThreadX continua a essere rilevante nei contesti in cui determinismo, maturità industriale e middleware integrati hanno un peso strategico.

La scelta corretta dipende da risorse hardware disponibili, requisiti di sicurezza, protocolli richiesti, processo di sviluppo, necessità di compliance e orizzonte di manutenzione del prodotto. Per questo motivo, selezionare un RTOS non dovrebbe mai essere una decisione presa solo sulla popolarità del nome o sulla disponibilità iniziale in un SDK, ma su una valutazione completa dell’intero ciclo di vita del sistema.

Riferimenti ufficiali

FreeRTOS – freertos.org • Licensing • Integrazione AWS • AWS IoT ExpressLink

Zephyr – zephyrproject.org • Build & Config • OpenThread / Thread • Documentazione ufficiale

Eclipse ThreadX – github.com/eclipse-threadx • FAQ ufficiale • Panoramica della suite storica