69 / 84
69
EMBEDDED
MAGGIO
OPEN SOURCE |
SOFTWARE
di gestione audio o video,
dove la perdita di qualche bit
o frame non pregiudica ne-
cessariamente la qualità del
À %
L’entità dei danni causati
dal mancato rispetto dei re-
quisiti di funzionamento può
essere molto diversa: una
cosa sono i danni all’incolu-
8 À
un’auto in un incidente stra-
dale, se l’airbag si apre trop-
po tardi, o anche troppo pre-
sto; un’altra sono le perdite
economiche e il calo d’imma-
gine che un’azienda subisce,
se in fabbrica il sistema d’i-
spezione automatica della
validità di ciascuna parte e componente che pro-
cede verso la linea di assemblaggio non compie le
proprie operazioni di analisi rispettando i corret-
ti requisiti di timing e sincronizzazione. In que-
sta applicazione, l’utilizzo di un sistema operati-
vo general-purpose, invece di un RTOS, potrebbe
causare accumulo di ritardi sull’intera linea di
assemblaggio, o portare alla consegna all’utente
À
%
Sviluppo del sistema: attenzione
ad alcuni aspetti chiave
Quando si sceglie di usare un RTOS, un primo
À 8 @
8
devono assegnare ai diversi task, e quale di essi
debba avere quella più alta. In questi casi, una
buona pratica è evitare modalità di assegnazione
delle priorità basate su proprie valutazioni perso-
nali di quali siano i task prioritari: meglio invece
À
#'H
(rate-monotonic scheduling), in grado di forni-
re già un buon punto di partenza, su cui si può
successivamente lavorare per eseguire ulteriori e
più precisi aggiustamenti delle priorità.
Altro aspetto cruciale è la fase di debugging del
sistema embedded, che tipicamente occupa molto
tempo e, nel caso di un RTOS, può complicarsi
ulteriormente: ciò è dovuto all’insorgere di vari
tipi di problemi, come, ad esempio, l’inversione
di priorità, o gli stati di “deadlock”, quelli in cui
il sistema va in fase di di stallo, per la presenza
di processi concorrenti nell’uso delle risorse. Per
ovviare a problemi come questi e velocizzare il
lavoro, è utile adottare tecniche e strumenti di
tracciamento, in grado di registrare quali even-
À
;
-
gono avviati e quando terminano l’esecuzione, e
quant’altro è utile a comprendere il comporta-
mento del RTOS. Ancora, è importante attuare
una buona gestione della memoria, che in un
RTOS embedded viene amministrata a diversi li-
velli, e tipicamente non è disponibile nelle quan-
tità riscontrabili nelle normali macchine desktop
G
À
il non rispetto di determinati requisiti in termini
di peso, o costo del sistema. Dunque, soprattutto
se il dispositivo embedded in questione dispone
di risorse hardware limitate, occorre ridurre al
massimo le dimensioni del codice del RTOS. Ad
esempio, specie negli RTOS dotati di un ricco
insieme di moduli e funzionalità, vanno disabi-
litate tutte quelle che non sono strettamente ne-
cessarie per l’applicazione, e che occupano molto
spazio nella RAM. Altro fattore determinante è
gestire in maniera corretta gli oggetti del RTOS,
e la modalità con cui viene allocata la memoria
del sistema: quest’ultima può essere assegnata
in modalità statica, oppure dinamica (basata su
heap). Le implementazioni “heap-based” possono
tuttavia determinare un impatto sulle prestazio-
ni real-time e sul comportamento deterministico
del sistema embedded.
Fig. 4 –
Fonte: Pixaba
y