Il Design for Test nello sviluppo embedded
Così come un PCB personalizzato necessita di test e valutazioni, anche un sistema embedded dovrà essere testato, sia a livello hardware che software. I sistemi embedded necessitano di test a più livelli, a partire dai chip durante la fase di produzione dei semiconduttori, fino all’assemblaggio del PCB attraverso una serie di test funzionali. Anche un’applicazione embedded, software o firmware, deve essere testata tramite un’interfaccia hardware. Tuttavia, molti utenti non affrontano questo aspetto nel modo più efficiente.
I progettisti hardware tendono a testare le applicazioni embedded nello stesso modo in cui testano i circuiti, usando multimetri o sonde per oscilloscopio. Invece di procedere alla cieca, segui questi suggerimenti per progettare sistemi embedded più facili da testare e monitorare.
Come gli ingegneri hardware affrontano solitamente i test dei sistemi embedded
Qualsiasi progettista di circuiti stampati dovrebbe sapere che un sistema embedded comprende un processore complesso e una serie di periferiche, ognuna delle quali può apparire come una scatola nera. Non è possibile sapere cosa succede all’interno della propria applicazione embedded, né come l’hardware risponde a essa, a meno che tu non integri funzionalità di monitoraggio sia nell’hardware che nel software/firmware embedded. Molti progettisti di circuiti stampati si limitano ad affrontare questo aspetto solo dal lato hardware, perché è l’approccio a cui sono abituati. Ciò si traduce spesso in un uso massiccio dei seguenti strumenti:
- Test point collegati a tutti i possibili pin di segnalazione su processori e periferiche
- Pin header aggiuntivi, che possono fungere sia da test point che da connessioni a moduli esterni
- Circuiti LED di segnalazione pilotati da stati logici o circuiti di alimentazione.
Una volta collegate tutte le sonde, i fili flottanti e i moduli esterni, il PCB comincia ad assomigliare a una creazione del dottor Frankenstein. Se l’obiettivo è testare le funzionalità software o firmware di un sistema embedded in relazione all’hardware, esistono soluzioni più efficaci per semplificare il design del prototipo e il processo di acquisizione dati.
Un design ottimizzato ti consente di limitare i collegamenti esterni solo a ciò che è davvero necessario, mentre tutto il resto può essere monitorato direttamente dal software.
Un approccio orientato al software
Il primo passo di un approccio orientato al software è predisporre un’interfaccia tra il prototipo del sistema embedded e un computer per l’acquisizione dei dati.
Durante i test, è fondamentale che il sistema embedded sia connesso a un computer in grado di monitorare l’applicazione mentre esegue le sue funzioni principali. Il metodo più semplice è usare una connessione seriale. Un tempo si utilizzavano interfacce come RS-232 o RS-485 con connettori DB9; oggi, la soluzione più comoda è connettersi tramite una porta USB e monitorare il sistema tramite interfaccia seriale.
L’altra opzione è utilizzare fili volanti conessi a un modulo DAQ, come quello mostrato nella figura qui sotto. Questi moduli possono essere gestiti tramite ambienti di test e misura come LabVIEW, oppure mediante software proprietari forniti dal produttore per il monitoraggio degli ingressi. I collegamenti di ingresso possono essere effettuati tramite cavi a nastro, fili volanti o entrambi; il DAQ si collega al computer tramite USB.
Il passo successivo è assicurarsi che il codice eseguito sul prototipo invii i dati giusti al computer. Per ottenere ciò, serve una buona pianificazione già nella fase di progettazione.
Pianificare in anticipo le connessioni
Quali connessioni sono necessarie per acquisire i dati dal prototipo? Come accennato in precedenza, potresti usare una connessione seriale al computer o un modulo DAQ che acquisisce i dati da fili volanti o cavi a nastro. Per trasferire i dati attraverso queste connessioni, puoi progettare una scheda con un’architettura semplice:
Queste soluzioni ti consentono di accedere ai dati e ai pin di segnalazione dei tuoi chip. Tuttavia, per gli indicatori di stato più importanti, è necessario implementare ulteriori funzionalità nella tua applicazione embedded.
Gestire gli errori nel tuo codice
L’elenco precedente mostra solo i modi per suddividere i GPIO e i pin indicatori importanti sugli ASIC, ma non dice nulla sulla tua applicazione reale. Il metodo più semplice per rilevare eventuali problemi in un’applicazione embedded è integrare meccanismi di gestione degli errori e indicatori di stato all’interno delle funzioni principali. Stampare su terminale dei flag di successo, fallimento o errore ti aiuta a individuare i problemi e a ridurre al minimo i tempi di debug.
Ad esempio, in MicroPython, un gestore di errori potrebbe essere implementato con una semplice funzione stdout.
Così facendo, avrai una descrizione testuale per ogni errore che si verifica nella tua applicazione. I gestori di errori devono essere descrittivi, indicando specificatamente quale parte del codice ha avuto successo o ha generato un errore. In questo modo è possibile seguire il progresso dell’applicazione attraverso ogni fase logica, evitando di dover rintracciare manualmente o emulare gli errori per eseguire il debug dell’applicazione. Quando si dispone di un’opzione di terminale sopra elencata insieme alle misurazioni dell’indicatore, si è in grado di vedere esattamente quando si verifica un errore e come questo coincide con la funzionalità dell’hardware.
La piattaforma di progettazione Allegro X offre un set avanzato di strumenti per PCB e opzioni di simulazione per l’analisi dei sistemi: scoprila subito.