85 / 100
85
DEBUG |
SOFTWARE
di sviluppo chiaramente inefficiente e poco affi-
dabile. Inoltre non è possibile essere certi che la
causa principale del problema sia stata corretta
in modo adeguato in quanto il problema potreb-
be ripresentarsi in circostanze differenti.
Tool di trace
L’impiego della tecnica di “software logging” (in-
cludere nel codice messaggi di debug), anche se
non è certo una novità, può contribuire a miglio-
rare sensibilmente il livello di conoscenza del si-
stema. In ogni caso, anche se i dati generati in
questo modo possono essere preziosi, ricavarne
informazioni utili non è sempre facile.
L’analisi dei dati di trace e la loro visualizza-
zione sono le funzioni principali del tool Trace-
alyzer di Percepio. Esso è in grado di offrire varie
viste grafiche, da una semplice lista di eventi a
sofisticati grafici che mostrano dipendenze tra
oggetti e statistiche avanzate.
Sono previste oltre 25 viste grafiche che mostra-
no differenti aspetti dell’esecuzione del software
che non sarebbero altrimenti disponibili utiliz-
zando solamente un debugger. TraceAnalyzer si
propone dunque come un valido complemento ai
tool di debug software esistenti e svolge un ruolo
essenziale nello sviluppo delle odierne applica-
zioni embedded caratterizzate da un elevato gra-
do di complessità.
Esso supporta un gran numero di sistemi ope-
rativi tra cui Linux; FreeRTOS; OpenRTOS,
On Time RTOS-32 e SafeRTOS di Wittenstein;
VxWorks di Wind River; μC/OS-III di Micrium
ed embOS di Segger.
La vista principale di Tracealyzer, come mo-
strato nelle figure 1(a) e 1(b), è una timeline
(sequenza temporale) verticale che visualizza
l’esecuzione di task/thread e interrupt. Gli altri
eventi registrati, come ad esempio le chiamate di
sistema (system call - che servono per ottenere
un servizio dal sistema operativo) sono visualiz-
zate con etichette testuali colorate. Sono previ-
ste numerose altre visualizzazioni della timeline
utilizzando un orientamento orizzontale e tut-
te le visualizzazioni orizzontali possono essere
combinate su una timeline orizzontale comune.
I dati più importanti sono generati dal kernel
del sistema operativo, ma gli sviluppatori posso-
no anche estendere il trace con gli “User Event”,
che consentono la registrazione di eventi o dati
dell’applicazione dell’utente. Essi sono registrati
in maniera del tutto analoga a quanto avviene
con una “printf” della libreria C, ma sono mol-
to più veloci perché la formattazione effettiva
dei dati è gestita nell’applicazione residente
sull’host e possono essere di conseguenza uti-
lizzati anche in un codice di tipo time-critical
(ovvero che ha vincoli temporali molto stretti da
rispettare) come le routine di gestione dell’inter-
rupt (interrupt handler).
Ovviamente essi possono essere correlati con al-
tri eventi del kernel.
Tracealyzer è in grado di “comprendere” nu-
merose chiamate al sistema operativo, come ad
esempio il blocco di un mutex (semaforo binario)
o la scrittura in una coda di messaggi. Ciò con-
sente al tool di effettuare analisi approfondite
per collegare ed evidenziare visivamente even-
ti correlati e generare grafici di dipendenza che
danno un riscontro visivo ad alto livello delle in-
terazioni tra task. Ciò consente agli sviluppato-
ri di analizzare in tempi brevi trace complessi e
di comprendere cosa stia succedendo realmente
all’interno dei loro sistemi.
EMBEDDED
60 • MAGGIO • 2016
Fig. 1(b) – Modificando la modalità con cui Con-
trolTask protegge una sezione critica, Sam-
plerTask è in grado di girare nel modo previsto