EMB_90

EMBEDDED 90 • NOVEMBRE • 2023 60 embedded orientato all’hardware. Oltre a questi metodi standard, i debugger hardware oggi offrono anche meto- di per il controllo dei test del software sul sistema di de- stinazione. In questo caso il debugger si collega all’har- dware target effettivo attraverso interfacce di debug standard, con lo scopo di sviluppare e testare il software embedded in una condizione il più possibile vicina a quel- la dell’hardware effettivo. Questo rappresenta un valido ausilio in particolar modo per quanto concerne i requi- siti di sicurezza, ovvero FFI, esecuzione e temporizza- zione nonché condivisione delle informazioni. Di seguito un’analisi relativa ad alcuni casi d’uso di test specifici. Quando si effettuano le impostazioni per il test unita- rio, il codice sorgente del software che si sta testando è cross-compilato per il dispositivo di destinazione e non instrumentato. Ciò significa che il codice di produzione originale è testato sul dispositivo target. Il controllo attuale del target per l’esecuzione del test, ov- vero il download del codice, la chiamata dell’unità, cioè la funzione C sottoposta a test, l’impostazione dei vetto- ri di input di test e la lettura dei risultati di test, viene effettuato dal debugger sottostante, come winIDEA con BlueBox di TASKING (Fig. 2). Come per l’esecuzione su un PC host, in questo caso Fig. 3 – Esempio di debug durante il test unitario, una funzione C “calculateFuelEfficiency” vrà corrispondere il più possibile all’ambiente di desti- nazione.” Allora perché non eseguire il test direttamente sul target? I tool di debug hardware sono usati tradizionalmente per lo sviluppo e il debug di driver, il bring-up di hardware/ schede, i processi di boot e molto altro. In altre parole, per lo sviluppo “minimamente invasivo” del software Fig. 2 – Debug dell’hardware e impostazione di test usando l’esempio di un sistema target basato su AURIX di Infineon SOFTWARE | DEBUG