Vero

Quando è necessario utilizzare un sistema operativo in tempo reale (RTOS) per un progetto embedded? Cosa porta sul tavolo e quali sono i costi? Fortunatamente esistono definizioni tecniche rigorose, che possono anche aiutare a capire se un RTOS è la scelta giusta per un progetto.

La parte “in tempo reale” del nome copre infatti la premessa di base di un RTOS: la garanzia che determinati tipi di operazioni verranno completate entro un arco di tempo predefinito e deterministico. All'interno del “tempo reale” troviamo categorie distinte: hard, firm e soft real-time, con sanzioni sempre meno severe in caso di mancato rispetto della scadenza. Come esempio di uno scenario difficile in tempo reale, immagina un sistema in cui il controller integrato deve rispondere ai dati del sensore in arrivo entro un intervallo di tempo specifico. Se la conseguenza del mancato rispetto di tale scadenza romperà i componenti a valle del sistema, in senso figurato o letterale, la scadenza sarà dura.

In confronto, il soft real-time sarebbe il tipo di operazione in cui sarebbe fantastico se il controller rispondesse entro questo intervallo di tempo, ma se impiegasse un po' più di tempo, andrebbe benissimo lo stesso. Alcuni sistemi operativi sono in grado di supportare l'hard real-time, mentre altri no. Questo è principalmente un fattore della loro progettazione fondamentale, in particolare dello scheduler.

In questo articolo daremo un'occhiata a una varietà di sistemi operativi, per vedere dove si adattano a queste definizioni e quando vorresti utilizzarli in un progetto.

Diversi sistemi operativi integrati si rivolgono a diversi tipi di sistemi e hanno set di funzionalità diversi. Il più minimalista degli RTOS popolari è probabilmente FreeRTOS, che fornisce uno scheduler e con esso primitive multi-threading inclusi thread, mutex, semafori e metodi di allocazione heap thread-safe. A seconda delle esigenze del progetto, puoi scegliere tra diversi metodi di allocazione dinamica, oltre a consentire solo l'allocazione statica.

All'altra estremità della scala troviamo RTOS come VxWorks, QNX e Linux con patch di pianificazione in tempo reale applicate. Si tratta generalmente di sistemi operativi certificati POSIX o compatibili, che offrono la comodità di sviluppare per una piattaforma altamente compatibile con le normali piattaforme desktop, offrendo al contempo un certo grado di garanzia di prestazioni in tempo reale, grazie al loro modello di pianificazione.

Ancora una volta, un RTOS è RTOS solo se lo scheduler garantisce un certo livello di determinismo quando si cambiano le attività.

Anche al di fuori del campo dei sistemi operativi, le prestazioni in tempo reale dei processori possono differire in modo significativo. Ciò diventa particolarmente evidente quando si esaminano i microcontrollori e il numero di cicli richiesti per l'elaborazione di un'interruzione. Per i popolari MCU Cortex-M, ad esempio, la latenza di interruzione varia da 12 cicli (M3, M4, M7) a 23+ (M1), nel migliore dei casi. Dividi per la velocità del processore e avrai circa un quarto di microsecondo.

In confronto, quando guardiamo la gamma di MCU 8051 di Microchip, possiamo vedere nel "Manuale hardware dei microcontrollori Atmel 8051" nella sezione 2.16.3 ("Tempo di risposta") che, a seconda della configurazione dell'interruzione, la latenza dell'interruzione può essere ovunque da 3 a 8 cicli. Sulle piattaforme x86 la storia è ancora più complicata, a causa della natura alquanto contorta degli IRQ x86. Ancora una volta, una frazione di microsecondo.

Questa latenza pone un limite assoluto alle migliori prestazioni in tempo reale che un RTOS può ottenere, sebbene a causa del sovraccarico derivante dall'esecuzione di uno scheduler, un RTOS non si avvicina a questo limite. Questo è il motivo per cui, per ottenere le migliori prestazioni in tempo reale, un approccio deterministico a ciclo di polling singolo con routine di gestione degli interrupt veloci per gli eventi in ingresso è di gran lunga il più deterministico.

Se l'interruzione, o altro cambio di contesto, costa cicli, l'esecuzione più veloce del processore sottostante può ovviamente anche ridurre la latenza, ma comporta altri compromessi, non ultimo il maggiore consumo energetico e maggiori requisiti di raffreddamento.

Come dimostra FreeRTOS, lo scopo principale dell'aggiunta di un sistema operativo è aggiungere il supporto multi-tasking (e multi-threading). Ciò significa un modulo di pianificazione che può utilizzare una sorta di meccanismo di pianificazione per suddividere il tempo del processore in "fette" in cui possono essere attivi diversi compiti o thread. Sebbene lo scheduler multi-tasking più semplice sia quello in stile cooperativo, in cui ogni thread si arrende volontariamente per consentire agli altri thread di fare le proprie cose, questo ha il netto svantaggio di ogni thread che ha il potere di rovinare tutto per gli altri thread.