Appunti Sistemi embedded e real time

RTOS

• Corrispondenza agli standard: generalmente le API sono proprietarie, ma gli RTOS

offrono anche compatibilità allo standard Real-Time POSIX

• Modularità e scalabilità: il kernel ha dimensione ridotta e le sue funzionalità sono

configurabili.

• Dimensione del codice: spesso sono basati su microkernel

• Velocità ed efficienza: basso overhead per cambi di contesto, latenza delle interruzioni

e primitive di sincronizzazione.

• Porzioni di codice non interrompibile: generalmente corte e di durata predicibile.

• Gestione delle interruzioni “separata”: interrupt handler corto e predicibile, ISR

lunga e di durata variabile.

• Gestione della memoria: possibilità di utilizzare la memoria virtuale e protezione

dello spazio di indirizzi del kernel.

Schedulazione nei principali RTOS

• Almeno 32 livelli di priorità differenti.

• Possibilità di scelta tra FIFO e Round Robin per la gestione dei task nello stesso livello

di priorità.

• Possibilità di cambiare la priorità a run-time.

• Generalmente non supportano nativamente politiche di scheduling a priorità

dinamica (es. EDF), oppure server a conservazione di banda.

• Offrono meccanismi di controllo dell’inversione di priorità: tipicamente priority

inheritance, alcuni anche priority ceiling.

Alcuni di questi meccanismi, come quelli di controllo dell’inversione di priorità posso essere

abilitati/disabilitati in fase di progetto.

Comunicazione, Sincronizzazione e Gestione della memoria negli RTOS

Gli RTOS mettono a disposizione diversi meccanismi per la comunicazione e sincronizzazione

dei task del sistema, come: memoria condivisa; mutex e semafori; code di messaggi, pipe, FIFO;

segnali.

Lo standard POSIX descrive come usare questi meccanismi in ambito real-time.

Per quanto riguarda la gestione della memoria, sappiamo che tutti i sistemi operativi moderni

supportano i principali meccanismi di gestione della memoria, come la memoria virtuale e la

protezione dello spazio di indirizzamento.

Al contrario, non tutti i sistemi operativi in ambito embedded e real-time supportano tali

meccanismi, e quelli che li supportano permettono di disabilitarne l’utilizzo in quanto non tutte

le applicazioni real-time (ed embedded) necessitano di tali meccanismi, i quali potrebbero

anche penalizzare i tempi di esecuzione.

Analizziamo nel dettaglio tali due meccanismi per sistemi embedded e real-time:

• Memoria virtuale: le applicazioni embedded e real-time sono a dimensioni contenute

e processano dati aventi dimensione prefissata. Di conseguenza, la mancanza del

meccanismo di memoria virtuale non è un problema.

Inoltre, l’overhead introdotto dal meccanismo di traduzione degli indirizzi della memoria

virtuale può essere particolarmente oneroso per un sistema embedded. Infine, si osservi

che l’RTOS generalmente alloca alle applicazioni blocchi contigui di memoria, e di

conseguenza i problemi di frammentazione della memoria sono minimi.

• Protezione della memoria: molti RTOS non forniscono meccanismi di protezione

dello spazio di indirizzamento per i processi del kernel e per le applicazioni.

Alcuni RTOS prevedono l’esecuzione dei task direttamente in modalità kernel, che ha

come conseguenza una particolare efficienza nel “passaggio” da un job all’altro. Si osservi

che l’uso di un unico spazio di indirizzamento (poiché non c’è protezione) implica una

semplicità nel task switching, e quindi una maggiore predicibilità (ovviamente ciò

comporta un maggiore sforzo nello sviluppo degli applicativi).

9.1.7 Esempi di sistemi operativi real-time

Esistono molti sistemi operativi RTOS, in particolare per sistemi embedded. Esempi di essi

sono: VxWorks

▪ LynxOs

▪ QNX Neutrino: sistema operativo per automobile che segue lo standard POSIX e

▪ presenta un’architettura a microkernel. È progettato intorno ad un meccanismo di

scambio di messaggi e segnali, implementato nel kernel stesso.

eCOS: è un RTOS open-source.

▪ FreeRTOS: è un RTOS open-source.

▪ 9.1.8 Windows Embedded

Microsoft offre una serie di OS embedded, come ad esempio Windows Embedded Compact

2013 e le versioni Windows mobile, ovvero sistemi orientati ai cellulari ma molto simili a

sistemi desktop, come Windows Phone 8.

Gli OS embedded della Microsoft hanno le seguenti caratteristiche:

• non sono versioni leggere di Windows;

• sono sistemi operativi basati su kernel monolitici;

• non sono compatibili con lo standard POSIX;

• il codice del kernel ha licenza shared-source;

• supportano solo architetture monoprocessore e difficilmente possono essere definiti

sistemi real-time. Presentano limiti architetturali molto forti, ad esempio non è possibile

creare un task a livello di priorità alto (cioè a un livello di priorità già predeterminato).

Quello che si fa è creare il task con priorità base, e quando esso va in esecuzione, cambia la

sua priorità, ma non sappiamo quando ciò avviene poiché task a priorità alta potrebbero

ritardare tale evento.

9.1.9 Zephyr

Progetto iniziato da Wind River per IoT. Dal 2006 coordinata dalla Linux Foundation e

sponsorizzato tra gli altri da Facebook, Google e Intel.

Tale RTOS possiede le seguenti caratteristiche:

• È un sistema completo che comprende kernel, librerie e driver.

• Ha un singolo spazio di indirizzamento ma con meccanismi di protezione della

memoria.

• Presenta scheduler a priorità fissa, con round robin opzionale.

• Supporta multiprocessore asimmetrico (i vari processori fanno tutte operazioni diverse)

e simmetrico.

• Implementa un sottoinsieme delle API POSIX.

• Integra molti protocolli di comunicazione, come IPv4, IPv6, OMA, Bluetooth Low

Energy, etc…

Tale RTOS è uno dei più apprezzati al momento, e tra quelli su cui convergono la maggior parte

delle risorse dell’ICT.

Capitolo 10 – Linux in ambito real-time

10.1 Linux in ambito real-time

È possibile utilizzare Linux come sistema operativo real-time, tuttavia, Linux non è un

sistema hard real-time in quanto, è progettato per massimizzare il throughput (cioè di

sfruttare l’hardware il maggior tempo possibile) delle applicazioni e minimizzare i tempi

medi di risposta.

Questi non sono gli obiettivi di un SO real-time: gli obiettivi richiesti sono la predicibilità

del sistema ed il rispetto delle scadenze. Tali proprietà devono essere previste sin dalla

fase di progettazione del SO, in modo da poter garantire che applicazioni real-time possano

rispettare le scadenze.

Sembra quindi che Linux non possa essere usato in ambito real-time. In realtà, Linux ha delle

caratteristiche interessanti per l’ambito real-time:

• Buona gestione dei timer software e del tempo.

• Gestione “separata” delle interruzioni.

• Schedulazione e gestione delle priorità dei task.

• Supporto alle politiche di accesso alle risorse condivise.

• Consente interruzione dei task anche in kernel mode, dunque è possibile sostituire il

processo in esecuzione con uno a priorità maggiore.

• Possibilità di creare facilmente task in kernel mode (non hanno una controparte in

user-mode). Questo velocizza i cambi di contesto e gestione della memoria (per essi si ha

un unico spazio di indirizzamento) quando avvengono solo tra task in kernel mode.

• Supporto alla memoria virtuale e protezione della memoria per i task in user mode

(cambio di contesto lento).

• Possibilità di configurare il kernel a grana fine, ovvero in fase di compilazione è possibile

decidere cosa includere/escludere.

• Il kernel è monolitico, ma il codice è open-source e quindi modificabile.

• È il SO con il maggior numero di architetture supportate.

• È il SO con il maggior numero di driver di periferiche disponibili.

Presenta comunità di sviluppo, supporto e sperimentazione molto attive.

10.1.1 Limiti di Linux come hard-RTOS

Nell’ambito soft real-time Linux non presenta problemi nel suo utilizzo, tuttavia, nell’ambito

hard real-time presenta un grosso problema: il suo limite principale è nella predicibilità

temporale di kernel e applicazioni (ovvero è difficile certificare che il sistema risponderà in

modo adeguato a eventi hard).

Tale problema deriva dal fatto che:

• Il kernel non è completamente interrompibile;

• Le interruzioni sono disabilitate nelle sezioni critiche (ad esempio quelle protette da

mutex o semaforo) poiché altrimenti potrebbero eseguiti flussi di codice che

richiedono le stesse primitive di sincronizzazione della sezione critica, e quindi si

possono generare deadlock;

• Le ISR possono avere una durata non predicibile;

• La gestione delle interruzioni non usa meccanismi di priorità.

In realtà, con difficoltà, è possibile modificare opportunamente il kernel Linux in modo da

renderlo sostanzialmente predicibile.

Ha senso usare il kernel monolitico di Linux per sistemi embedded? Si, dato che il kernel Linux

è estremamente configurabile, da cui è possibile ridurne drasticamente le dimensioni (non è

adatto per sistemi embedded di fascia bassa, come ad esempio il firmware delle chiavette

USB).

Gestione delle interruzioni in Linux

Molti problemi legati all’uso di Linux in ambito real-time sono dovuti alla gestione delle

interruzioni:

• Le interruzioni hanno priorità più elevata dei processi, di conseguenza in tal modo

posso rallentare applicazioni hard real-time.

• Si utilizza una gestione “separata” a 3 livelli:

La prima parte della gestione (top half) si compone di interrupt handler e la

o parte immediata dell’ISR. In particolare, l’interrupt handler salva e recupera

il contesto interrotto e dà conferma della ricezione dell’interruzione. La parte

immediata dell’ISR interagisce con la periferica hardware ed eventualmente

“prenota” la successiva esecuzione del bottom half.

La seconda parte della gestione (bottom half) svolge operazioni

o generalmente lunghe e interrompibili. È costituita da una procedura da

eseguire quando nessun altro top half è in esecuzione, quindi viene eseguita

quando si verifica una delle due seguenti situazioni:

immediatamente prima di tornare ad eseguire un processo;

▪ per mezzo di un kernel thread.

▪

• Le interruzioni possono interrompersi tra loro, il quale è un problema dato che le

interruzioni non hanno priorità. Se, ad esempio, ho in esecuzione un interrupt di un

processo