EMB_85

EMBEDDED 85 • SETTEMBRE • 2022 60 SOFTWARE | HW DEBUG N egli anni 90 vi erano sostanzialmente due so- luzioni basate su tool per il debug (ovvero l’individua- zione di errori) del software embedded sull’hardware reale. Il primo era il monitor debugger, ovvero una porzione di software programmato nella memoria del sistema embedded che reagiva alle richieste di un debugger software all’esterno. Il secondo era l’e- mulatore in-circuit (Fig. 1), un dispositivo hardware di grandi dimensioni che replicava ed emulava il mi- crocontrollore/microprocessore presente nel sistema hardware target per adattamento. La prima soluzione, ovvero il monitor debugger, era economica e in grado di soddisfare le esigenze delle funzioni basilari di debug, mentre l’emulatore in-cir- cuit era una soluzione costosa e di difficile utilizzo e il processo di adattamento era spesso instabile e soggetto a errori. Per contro, lo sviluppatore aveva la completa trasparenza e l’accesso a tutti i bus del microcontrollore/processore. A quel tempo era già possibile eseguire sia misure di temporizzazione del software sia l’analisi della copertura del codice (code coverage). In ogni caso, i produttori di semiconduttori dovevano sviluppare il cosiddetto chip di emulazio- ne, un dispositivo “ad hoc” dotato dei necessari pin aggiuntivi. Ovviamente ciò aveva un risvolto sui costi per tutti i soggetti coinvolti. La crescente miniaturizzazione dei semiconduttori e l’introduzione di interfacce di debug “on-chip” han- no avuto un impatto notevole sull’architettura di un Uno sguardo all’evoluzione del debug I progressi tecnici che hanno caratterizzato l’industria dei semiconduttori hanno contribuito a modificare il processo di sviluppo del software e di conseguenza anche il debugger, divenuto un vero e proprio tool di processo Erol Simsek CEO iSYSTEM Fig. 1 – Emulazione in-circuit alla fine degli anni 80