EMB_85

EMBEDDED 85 • SETTEMBRE • 2022 62 SOFTWARE | HW DEBUG relative all’esecuzione del software senza influenzare il funzionamento in runtime (durante l’esecuzione). Lo sviluppatore ottiene un’immagine reale dell’esecuzione del software sull’hardware. Risulta così possibile individuare “colli di bottiglia” ed errori che si verificano sporadicamente nel software. Questo è giusto un esempio dei molti casi d’uso alternativi di un debugger. Microcontrollori, processori e SoC L’evoluzione del debug è avvenuta di pari passo con la miniaturizzazione dei semiconduttori, divenuti con il trascorrere del tempo sempre più complessi e veloci. Negli ultimi 15 anni, il settore embedded, in particola- re l’industria automotive, ha sperimentato l’introdu- zione di numerose funzionalità aggiuntive nei propri prodotti per soddisfare le normative in materia am- bientale (sia presenti sia future), per ridurre il nume- ro di incidenti stradali in generale, per sviluppare e produrre veicoli in modo più efficiente distribuendo le varie funzioni in molteplici centraline elettroniche (ECU – Electronic Control Unit) invece di implemen- tare una ECU specifica per ciascuna funzione, oltre che per differenziarsi dalla concorrenza. Per conse- guire tali obiettivi, l’industria automotive doveva fare affidamento su produttori di semiconduttori in grado di soddisfare le sue esigenze mediante lo sviluppo di microcontrollori più compatti ed efficienti. Da qui l’introduzione dei microcontrollori embedded multicore, ovvero dotati di due o più core. Il passag- gio da architetture a core singolo ad architetture mul- ticore nelle ECU ha comportato l’insorgere di nuove problematiche per tutti gli attori coinvolti. I fornitori di tool software embedded si sono trovati ad affronta- re nuovi problemi, da come poter accedere in modo semplice a tutti i core di una ECU multicore a come distribuire il software embedded e legacy su differen- ti core che operano in maniera più efficiente pur man- tenendo elevate prestazioni. A questo punto la moda- lità tradizionale di sviluppo del software embedded ha iniziato a mostrare i propri limiti. Con l’introduzione delle piattaforme di elaborazione ad alte prestazioni e dei sistemi a più core, architet- ture di processore ancora più complesse vengono ora utilizzate per lo sviluppo di applicazioni molto evo- lute. A questo punto è utile porsi la domanda circa il ruolo del debug. In linea di principio, non vi sono cambiamenti. Oltre alla flash interna del microcon- trollore, è anche necessario prendere in considera- zione la flash esterna del SoC. I debugger, in primo luogo, aiutano a controllare il processo di boot (avvio) e quindi, nella fase successiva, a esaminare in modo approfondito le singole componenti e i core di questi processori, oltre al software che gira su questi dispo- sitivi. A causa della crescente complessità di questi sistemi software, oltre alle funzioni di debug standard vengono utilizzate in misura sempre maggiore svaria- te opzioni di analisi tra cui analisi delle temporizza- zioni, profilazione delle funzioni o misure del carico della CPU (Fig. 3). Pre-requisiti essenziali sono la di- sponibilità di interfacce per il trace sui dispositivi a semiconduttore utilizzati e il relativo debugger dotato del software necessario per implementare tali funzio- ni. I progressi tecnici che hanno caratterizzato l’indu- stria dei semiconduttori hanno contribuito a modifi- care il processo di sviluppo del software e di conse- guenza anche il debugger, che si è trasformato da tool fondamentale a tool di processo. Processi di sviluppo software e standard Team di sviluppo distribuiti, un codebase sempre più complesso, aumento dei requisiti funzionali, standar- dizzazione e vincoli temporali sempre più stringenti: anche nel settore dello sviluppo del software embed- ded, le problematiche legate all’introduzione di un prodotto affidabile e sicuro sul mercato nel più breve tempo possibile possono essere risolte solamente con livelli di astrazione e automazione più elevati. Per tale motivo i tradizionali tool di sviluppo devono garantire la massima versatilità. In precedenza, ap- pannaggio solamente di esperti in microcontrollori Fig. 3 – winIDEA Analyzer di iSYSTEM: sulla sinistra vi sono gli oggetti registrati mentre sulla destra è visibile la loro correlazione temporale