EMB_90

EMBEDDED 90 • NOVEMBRE • 2023 63 I n un’applicazione RTOS multi-thread, uno degli aspetti più sottovalutati è il fatto che non sia sufficiente esaminare il codice per comprendere appieno il comportamento e le prestazioni dell’applicazione stessa. Infatti, è necessario conoscere in che modo le varie componenti comunichino tra di loro e disporre di numerose altre informazioni: il tempo richiesto per l’esecuzione dei task, esistenza di potenziali condizioni di “race” (fuga) o deadlock (stallo), la conformità ai requisiti di temporizzazione e così via. Il comportamento dell’applicazione previsto dallo sviluppatore e quello effettivo possono differire in molti modi, per cause difficili da identificare nel codice e da rilevare mediante il collaudo funzionale. Ciò rappresenta una sfida per tutti gli sviluppatori che lavorano con codice multi- thread, indipendentemente dal fatto che usino un RTOS o Linux, che può essere affrontata in modo efficace con tool di diagnostica basati sul trace visuale. Grazie ad essi è possibile avere informazioni dettagliate su quello che si può definire il “lato oscuro” del codice – in altre parole vedere come si comporta durante l’esecuzione. Un diagramma visuale temporale è sicuramente un ottimo punto di partenza. Vedere gli eventi software, i messaggi e le esecuzioni dei diversi tasknel tempo è importante inparecchie situazioni, come nel caso in cui la posizione precisa del bug non sia ovvia sulla base dei sintomi – il computer garantisce prestazioni eccezionali quando si tratta di eseguire calcoli comunque complessi oppure di effettuare ricerche all’interno di file testuali, ma spesso non sa esattamente cosa cercare. Il cervello umano, per contro, eccelle nel riconoscimento di pattern visivi. Più dettagliate sono le informazioni in fase di debug, minore sarà il numero di ipotesi da prendere in considerazione e maggiori saranno le probabilità di individuare la causa principale (o le cause). Ciò rappresenta anche un valido ausilio in tutti i casi in cui non sia possibile ricorrere a un metodo tradizionale, come l’arresto del sistema in corrispondenza dei breakpoint. A questo punto si potrebbe pensare al debug mediante printf. Anche se si tratta di un metodo semplice da utilizzare e talvolta in grado di soddisfare tutte le esigenze, presenta alcuni svantaggi. Introdurre stampe (printout) di debug nel codice di un’applicazione “time-sensitive” è un’operazione rischiosa e non adatta nel caso di applicazioni più complesse e in presenza di processori operanti ad alta velocità. Inoltre, la funzione printf è abbastanza lenta, dell’ordine di parecchi millisecondi per stampa. Per contro, una soluzione ottimizzata per il tracing di eventi software può risultare 100 volte più veloce, consentendo di acquisire una quantità molto maggiore di informazioni nel medesimo periodo di tempo. La misura delle temporizzazioni e delle prestazioni durante l’intero processo di sviluppo riveste un’importanza fondamentale. Fatto in modo scrupoloso, ciò assicura la Cinque passi per semplificare il debug di applicazioni multithread Un’analisi di cinque semplici pratiche che permettono di ricavare le informazioni necessarie sul comportamento real-time a livello di sistema, per migliorare la qualità del prodotto, accelerare lo sviluppo e ridurre il time-to-market Johan Kraft CTO Percepio RTOS | SOFTWARE