86 / 100
EMBEDDED
60 • MAGGIO • 2016
SOFTWARE
|
DEBUG
86
Alcuni esempi pratici
Nel primo esempio riportato all’inizio dell’arti-
colo, in cui un task a elevata priorità veniva in-
spiegabilmente ritardato in modo intermittente,
si è fatto ricorso a Tracealyzer per mostrare gra-
ficamente il task in questione (“SamplerTask”),
correlandolo dal punto di vista temporale con gli
altri task. Con questo tool è stato possibile in-
dividuare in modo semplice i casi estremi della
temporizzazione dei task. Grazie allo zoom su un
particolare istante relativo al task che era sta-
to ritardato (fig. 1a) si è scoperto che un task a
più bassa priorità (“ControlTask”) stava disabi-
litando gli interrupt per proteggere una sezione
critica, bloccando in tal modo lo schedulatore
dell’RTOS con conseguente ritardo dell’avvio di
SamplerTask. Dopo aver cambiato in modo in cui
ControlTask proteggeva la sezione critica, uti-
lizzando un mutex anziché disabilitare gli inter-
rupt, SamplerTask è stato in grado di soddisfare
i requisiti di temporizzazione richiesti, come ri-
portato in figura 1(b).
Nel secondo esempio all’inizio dell’articolo, è sta-
to utilizzato un “User Events” non solo per rile-
vare quando il Watchdog sia scaduto e sia stato
resettato, ma anche il valore residuo del timer,
ovvero il margine temporale al termine del quale
si effettua il reset del si-
stema. Tramite l’ispezio-
ne delle chiamate di si-
stema registrate si è sco-
perto che il task in que-
stione non solo resettava
il timer del Watchdog,
ma inviava anche un
messaggio a un altro task
utilizzando una coda di
messaggi. I reset di si-
stema sembravano veri-
ficarsi mentre il task del
Watchdog era bloccato
da questa operazione di
invio del messaggio, a
causa del fatto che a vol-
te la coda dei messaggi
potesse essere piena. Il
problema era compren-
dere la ragione di questo
comportamento. Metten-
do in relazione la visualizzazione del carico della
CPU con la variazione dei margini temporali del
timer del Watchdog (Fig. 2) è stato possibile sco-
prire che un task di media priorità (ServerTask)
richiedeva così tanto tempo di CPU da impedire
la lettura della coda dei messaggi nei tempi pre-
visti da parte del task ricevente a più bassa pri-
orità. La coda risultava così piena e provocava il
blocco di SamplerTak che a sua volta era respon-
sabile dell’esaurimento del tempo prefissato per
il watchdog e del successivo reset del sistema. In
questo caso il problema è stato risolto modifican-
do le priorità dei task.
La complessità del software embedded cresce
a ritmi molto sostenuti, provocando un aumen-
to della richiesta di tool di sviluppo sempre più
avanzati. Mentre i dati possono essere registra-
ti run-time (ovvero nel corso dell’esecuzione) in
vari modi, la comprensione del loro significato
non è un’operazione semplice.
Per questo motivo tool innovativi per la visualiz-
zazione dei dati possono rappresentare un valido
ausilio.
Grazie ad essi i sistemi embedded si trasforme-
ranno da “black box” – che costringono gli svilup-
patori a fare supposizioni su ciò che sta avvenen-
do – in una “open box”.
Fig. 2 – Il grafico del carico della CPU correlate con l’”User Event”
relative al Watchdog Timer fornisce indicazioni molto utili