Codificare il Proprio Strumento di Test in Rete

Introduzione

Se avete mai trascorso del tempo a testare manualmente lotti di componenti, saprete quanto il processo possa essere laborioso e richiedere tempo. Ogni test segue gli stessi passaggi di base ripetuti per ogni articolo che state testando. Capirete anche il potere di utilizzare strumenti di test che potete programmare per eseguire questi passaggi per voi, così è semplicemente questione di impostare tutto e collegare tutto insieme in modo da poter premere un pulsante per eseguire un test. Potete risparmiare ancora più tempo automatizzando la configurazione di tutti i vostri strumenti di test con un clic del mouse del computer.

Tuttavia, cosa succede se volete creare strumenti di test personalizzati da aggiungere alla vostra suite di test automatizzati? Questa guida passo dopo passo vi mostrerà come scrivere codice che vi permetta di configurare i vostri strumenti di test in rete comodamente dal vostro computer.

L'automazione in rete elimina la necessità di impostare ogni pezzo di strumentazione di test separatamente e risparmia tempo se è necessario ripetere gli stessi test in futuro. Il vantaggio è che ripristinare le impostazioni dopo un'interruzione di corrente o lo spegnimento accidentale dell'attrezzatura è rapido e semplice.

Introduzione a SCPI

Se non siete familiari con la strumentazione di test in rete, dovete conoscere i Comandi Standard per Strumenti Programmabili (SCPI). In passato, Hewlett-Packard ha ideato il concetto di un bus di interfaccia standard che permetterebbe a qualsiasi computer con l'interfaccia corretta di connettersi a qualsiasi pezzo di strumentazione di test. Questo standard HPIB è diventato noto come General Purpose Interface Bus (GPIB) con la propria designazione standard IEEE 488. Questa standardizzazione ha permesso a ogni pezzo di strumentazione di test in rete di rispondere ai comandi del computer per eseguire funzioni come emettere un segnale o eseguire una misurazione.

SCPI ha ampliato il principio della standardizzazione della rete di strumentazione di test aggiungendo un ulteriore strato per lo standard IEEE-488 per regolare i comandi del computer che la strumentazione di test potrebbe comprendere. Questo approccio significa ora che un oscilloscopio prodotto da HP risponderà agli stessi comandi di un oscilloscopio prodotto da Keysight. Prima della standardizzazione dei comandi, spesso diversi modelli prodotti dallo stesso produttore reagivano a comandi differenti. Questa standardizzazione significa che il programma di controllo della strumentazione di test su un computer funzionerà con qualsiasi marca e modello di attrezzature da laboratorio, quindi cambiare, ad esempio, un alimentatore da banco in rete con un modello migliore non richiederà modifiche al programma di controllo.

Questa standardizzazione significa anche che qualsiasi codice scritto per questa guida passo dopo passo funzionerà in qualsiasi altro laboratorio se avete gli stessi tipi di strumentazione di test in rete collegati a un computer adatto.

Introduzione a SCPI

I comandi SPCI sono sotto forma di semplici stringhe ASCII che sono ragionevolmente intuitive da leggere e comprendere. Ad esempio, inviando il comando “*RST” a un apparecchio di test lo reimposterà; inviando il comando “*WAI” lo istruirà ad attendere.

I comandi SPCI possono istruire l'apparecchiatura di test a eseguire un'azione o richiedere informazioni a seconda del suo formato. Ad esempio, il comando “TIM:ACQT 20ms” cambierà il tempo di acquisizione di un oscilloscopio a 20ms, mentre il comando “TIM:ACQT?” farà sì che restituisca il suo tempo di acquisizione corrente.

Punti importanti da considerare sono che i comandi non sono sensibili al maiuscolo/minuscolo e supportano forme abbreviate, quindi, ad esempio, “TRIG SOUR CH1” e “Trigger source Channel1” sono entrambe alternative valide dello stesso comando. È possibile anche concatenare i comandi, quindi ad esempio, “TRIG SOUR CH1”, “TRIG LEVEL1 10” e “TRIG POL INV” possono essere scritti come “TRIG:SOUR CH1;LEVEL1 10;POL INV” poiché tutti i comandi si applicano allo stesso TRIG. Questi comandi impostano il canale sorgente, il suo livello in volt e la polarità. Questo esempio imposta il livello del canale 1 a 10V con polarità invertita. Non è necessario specificare il suo trigger 1 poiché questo è sottinteso, ma si potrebbe usare “TRIG1:” per evitare ambiguità.

Il Progetto di Codifica

Il video che accompagna questo articolo mostra come creare la propria apparecchiatura di test in rete che utilizza comandi SCPI. Questo si basa su un video precedente che mostra come comunicare con l'apparecchiatura di test per l'automazione.

L'obiettivo di questo esercizio è consentire all'hardware di test personalizzato di integrarsi senza problemi in qualsiasi software di test esistente che può gestire comandi SCPI, come quelli che utilizzano le LAN eXtensions for Instrumentation (LXI) o l'architettura software per strumenti virtuali (VISA). L'obiettivo finale è sviluppare un dispositivo di test integrato e completo incorporando un microcontrollore nell'hardware di test automatizzato.

Il cuore del progetto è la scheda di sviluppo Infineon XMC4700 Relax Kit, realizzata per applicazioni industriali. La scheda include un microcontrollore con memoria statica e dinamica, orologi, alimentatori, interfacce standard e controlli di base. Include anche una connessione ethernet integrata con un indirizzo di controllo di accesso al mezzo (MAC) per la rete.

Un vantaggio chiave di questa configurazione è la disponibilità dell'ambiente di sviluppo integrato Digital Application Virtual Engineer (DAVE) che Infineon fornisce. DAVE è uno strumento di sviluppo software e generazione di codice basato su C per applicazioni microcontrollate. Permette di semplificare il processo di codifica, gestendo comodamente la maggior parte dei compiti di configurazione in modo che ci si possa concentrare sull'implementazione dei comandi SCPI.

Il codice di test che creeremo leggerà la posizione di un pulsante e controllerà lo stato di un LED. Questo test semplificato offrirà un esempio facile da comprendere e fornirà un ottimo punto di partenza per ulteriori esplorazioni del potere e dei benefici del testing automatizzato.

Guida alla Codifica Passo Dopo Passo

Configurazione del Progetto:

Quando si utilizza lo strumento DAVE per un nuovo progetto, il primo passo è creare un nuovo file di progetto utilizzando la sequenza di comandi “File -> Nuovo -> Progetto DAVE”. Questa azione aprirà una nuova finestra dove potrai selezionare l'opzione “Progetto DAVE CE” e dargli un nome appropriato.

Dovrai poi scegliere il tuo hardware target; in questo caso, il kit XMC4700 Relax.

A meno che il tuo progetto non sia limitato in termini di risorse, è sempre una buona pratica utilizzare la libreria standard newlib completa piuttosto che l'opzione di dimensioni nano.

Il passo successivo è configurare i periferici per il progetto utilizzando il comando “DAVE -> Aggiungi Nuova APP”.

La prima configurazione da impostare è la connessione di rete, e lo fai con il comando “Ethernet -> ETH_LWIP”, che aggiunge uno stack di protocollo internet (IP) leggero al progetto per gestire questa interfaccia.

Dovrai anche aggiungere le interfacce di input/output (IO) per lo strumento di test, il pulsante e l'indicatore LED in questo esempio. Entrambi sono componenti discreti, quindi devi aggiungere due “app DIGITAL_IO” sotto l'opzione del comando Sistema, una per ciascun elemento.

È una buona pratica rinominare le app IO per identificare le loro funzioni nei nomi per semplificare la vita e prevenire l'accesso accidentale all'app sbagliata. Questo errore può essere difficile da individuare quando si cerca di eseguire il debug di un programma di test che si comporta in modo inaspettato.

Devi anche configurare lo stack IP per la connessione Ethernet facendo clic con il tasto destro su "ETH_LWIP App" e cliccando su "Configura istanza APP". Scoprirai che il kit XMC4700 Relax è già preconfigurato, il che fa risparmiare tempo. Dovrai modificare l'indirizzo IP statico nella pagina delle impostazioni IP per corrispondere al sottorete del computer che stai utilizzando per i tuoi test automatizzati. Inoltre, il protocollo user datagram (UDP) non è richiesto in questo esempio, quindi puoi disattivarlo nella scheda delle impostazioni del protocollo.

Infine, devi fornire la mappatura tra le impostazioni dei pin dell'APP e l'hardware del microcontrollore utilizzando l'opzione di allocazione manuale dei pin per ogni componente. Per configurare il pulsante discreto, fai clic con il tasto destro sul pulsante e seleziona il comando "Allocatore manuale dei pin".

Puoi quindi scegliere il numero di pin appropriato per il pulsante sul Relax Kit dal menu a discesa, che fornisce comodamente le etichette per rendere questo processo semplice. La configurazione del LED e della connessione Ethernet seguono lo stesso processo. Scoprirai che la funzione di allocazione dei pin semplifica questo processo consentendoti di selezionare solo i pin con la funzionalità necessaria. Lo strumento fornisce automaticamente tutte le etichette del kit XMC4700 Relax per rendere questo processo semplice.

Questi passaggi completano la configurazione per il tuo progetto di test automatizzato e ora sei pronto per scrivere il codice di test.

Codifica dell'App del Progetto

È possibile generare il codice per le App semplicemente cliccando sul pulsante "Genera Codice" sulla barra degli strumenti di DAVE e poi attendere che l'operazione si completi.

Prima di iniziare a programmare seriamente, si raccomanda di trasferire la console dal microcontrollore al computer, fornendo un facile accesso a `printf`. Questo vi permetterà di formattare e stampare dati per rendere la scrittura e il debug del codice più rapidi e semplici. Potete farlo abilitando il "GDB Semi-Hosting" nelle impostazioni di configurazione. Questo si può fare navigando nelle "Proprietà del Progetto", procedendo poi in "C/C++ Build" e selezionando "Impostazioni".

In "ARM-GCC, C Linker, Varie", dovrete aggiungere "--specs=rdimon.specs" alle "Altre" flag. Questo passaggio incorpora la configurazione del semi-hosting per il linker.

Potete poi andare nella sezione "ARM-GCC C Compiler, Preprocessore" e aggiungere un nuovo simbolo definito di "XMC_DEBUG_ENABLE". Questa impostazione assicura il reindirizzamento della console nella configurazione di build di debug.

Dovrete nelle impostazioni del progetto deselezionare la casella che fornisce "default newlib system calls" sotto le impostazioni di "ARM-GCC C Linker, Generale". Se lasciate questa opzione selezionata, scoprirete che interrompe l'inizializzazione del gestore del monitor e causa il fallimento della build.

Successivamente, è necessario inizializzare il monitoraggio, cosa che potete fare aggiungendo "extern void initialise_monitor_handles(void);" all'inizio del vostro codice. Questa funzione deve essere chiamata dopo la chiamata a DAVE_Init();.

Si noti che l'ortografia di "initialise" è la variante in inglese britannico poiché la base ARM si trova a Cambridge, Inghilterra. Usare l'ortografia americana genererà un errore che può essere difficile da risolvere se non si nota la sottile differenza di ortografia.

Codifica di Rete del Progetto

Il primo passo per far funzionare la rete Ethernet è abilitare lo stack IP leggero per controllare regolarmente i nuovi messaggi. Potete farlo aggiungendo una chiamata alla funzione "sys_check_timeouts();" all'interno del vostro ciclo while infinito che viene eseguito dopo il completamento dell'inizializzazione.

Questa funzione avrà bisogno di essere sottoposta a debug per consentirle di funzionare sul microcontrollore. Puoi farlo creando una nuova configurazione di debug. Si raccomanda di disattivare l'opzione “Imposta breakpoint su: main” per permettere al codice di eseguirsi non appena il microcontrollore si avvia. Selezionando l'opzione di debug verrà caricato il tuo nuovo codice nel microcontrollore.

Puoi confermare che il codice è in esecuzione aprendo una console Windows sul tuo computer e facendo ping all'indirizzo IP della scheda di sviluppo, che in questo esempio, è il kit XMC4700 Relax. La scheda di sviluppo dovrebbe rispondere ad ogni ping, confermando che la scheda è operativa e la connessione di rete funziona.

Il codice dello stack IP leggero gestirà automaticamente le funzioni del Protocollo di Controllo dei Messaggi Internet (ICMP). Tuttavia, devi creare codice per gestire le connessioni in entrata e i dati del Protocollo di Controllo della Trasmissione (TCP). Puoi farlo utilizzando dichiarazioni di codice standard dello stack IP leggero che non sono specifiche per il microcontrollore.

Ora che hai completato la configurazione della connessione di rete, puoi impostare il blocco di controllo del protocollo per ascoltare sulla porta 5025, che il codice SCPI utilizza per le comunicazioni. Dovresti configurare lo stack IP leggero per delegare tutte le nuove connessioni a una funzione chiamata client_accept che dovrai estendere per gestire nuovi clienti. Tutti i dati ricevuti dovranno essere reindirizzati a una funzione di elaborazione separata che emetterà anche un messaggio di debug per indicare la ricezione di una nuova connessione.

Implementare un metodo client_recv copierà i dati ricevuti in un buffer per l'elaborazione. Questa funzione dovrebbe anche controllare le connessioni senza dati, il che indica che l'host remoto ha chiuso la connessione. Per questa condizione, il codice può eseguire azioni di pulizia per rimuovere eventuali artefatti indesiderati lasciati dalla connessione chiusa.

Compilare il codice genererà una build funzionale se non ci sono errori di codifica da correggere.

Codifica IO del Progetto

Il passo successivo è la configurazione delle “App IO Digitali” per eseguire le loro operazioni richieste.

Fare clic con il tasto destro su ogni App e selezionare l'opzione "Configura istanza App". L'impostazione predefinita per i componenti IO è un ingresso tristato, perfetto per il pulsante. Tuttavia, per il LED, sarà necessario cambiare le impostazioni in "Input/Output" con una forte corrente di guida e un bordo morbido. Questa configurazione di forte corrente assicura che la scheda produca abbastanza corrente di guida per illuminare il LED. La configurazione di bordo morbido si riferisce alla velocità di transizione del bordo del pin. Un bordo morbido attenua qualsiasi effetto transitorio sulla rete di distribuzione dell'energia e riduce il rischio di un impatto negativo sulla conformità elettromagnetica. Utilizzare questa opzione per l'uscita discreta è una buona pratica a meno che non sia necessario un segnale con velocità di bordo in nanosecondi.

Rigenerare il codice aggiornato aggiungerà queste nuove modifiche alla build funzionale. È importante ricordarsi di rigenerare sempre il codice dopo aver apportato qualsiasi modifica a un'App DAVE.

Codifica SCPI del Progetto

Con le funzioni di configurazione e inizializzazione completate, la codifica del progetto può finalmente procedere per implementare i comandi SCPI per i test. Non è necessario implementare i comandi SCPI da zero; è disponibile su GitHub una eccezionale libreria SCPI-Parser di Jan Breuer come punto di partenza.

Puoi sfruttare questa risorsa estraendo la cartella libscpi nella cartella Libraries del tuo progetto. Quindi estrarre le cartelle scpi-def da "examples -> common" nella tua cartella del progetto. Questo passaggio importa la libreria SCPI-Parser e fornisce un buon punto di partenza per implementare il tuo progetto.

Dovrai eliminare la cartella test e il makefile nella libreria libscpi all'interno dell'ambiente di sviluppo integrato di DAVE, poiché saranno incompatibili con la libreria ARM-GCC in uso.

Quindi tornare alla finestra delle proprietà del progetto sotto "Build, Settings, Compiler, Directories" e aggiungere un riferimento alla cartella include di libscpi.

Dovrai anche aprire il file scpi-def.c e aggiungere un'istruzione include per "dave.h" per collegare le tue funzioni IO al file scpi-def.

Come nota a margine, questo file include un'eccezionale implementazione dimostrativa di un multimetro digitale e funzioni per test automatizzati. Purtroppo, queste funzioni sono incompatibili con il compilatore ARM utilizzato per questo esempio e quindi devono essere rimosse. Tuttavia, se in futuro avrai bisogno di implementare le tue funzioni, potrai fare riferimento ai file originali per consultazione.

Quando modifichi il file, elimina tutte le funzioni DMM e di test nel blocco di configurazione dei comandi ma conserva il codice per il comando TST e tutte le dichiarazioni seguenti, insieme ai comandi SCPI standard che la libreria gestirà.

È possibile definire le informazioni di identificazione per la configurazione del test nel file “scpi-def.h”, così utilizzando il comando SCPI *IDN verranno restituite informazioni utili in risposta a qualsiasi richiesta di identificazione.

È possibile impostare i comandi SCPI nel file “main.c” del progetto. Sarà necessario aggiungere il contesto SCPI alla funzione principale utilizzando la proprietà user_context per passare un riferimento al blocco di controllo del protocollo Lightweight IP consentendo l'inizializzazione della libreria SCPI. Poi è necessario aggiungere le proprie funzioni per abilitare libscpi a comunicare tramite la connessione di rete. In questo esempio, le seguenti funzioni devono essere definite:

• La funzione “SCPI_Write” permette a libscpi di inviare dati tramite la connessione di rete.

• La funzione “SCPI_Flush” notifica allo stack Lightweight IP di inviare immediatamente qualsiasi dato presente nel buffer.

• La funzione “SCPI_Error” fornisce un modo per gestire gli errori SCPI. Per questo esempio di base, è possibile bypassare ciò con una semplice chiamata alla funzione printf.

• La funzione “SCPI_Control” è una caratteristica opzionale che consente di scrivere sul canale di controllo sulla porta TCP 5026, che non sarà necessaria per questo esempio.

• La funzione “SCPI_Reset” viene chiamata in risposta alla ricezione di un comando di reset, riportando tutti gli strumenti di test alle loro impostazioni predefinite. Non essendoci strumenti di test collegati per questo esempio di base, è possibile bypassare ciò con una semplice chiamata alla funzione printf.

Infine, il user_context deve essere impostato per la nuova connessione client quando si effettua una connessione allo stack Lightweight IP. Ciò consentirà di passare i dati alla libreria SCPI dal buffer tramite la funzione client_recv a “SCPI_Input” per essere elaborati. È necessario notare che questa implementazione non gestirà connessioni multiple simultaneamente ma rappresenta una buona pratica di configurazione di rete.

Compilando il codice aggiornato e caricandolo sul microcontrollore dovrebbe risultare in un sistema di test che non solo continua a rispondere ai ping da una Console Windows ma dovrebbe anche rispondere ai comandi SCPI.

Test del Codice SCPI del Progetto

Questo progetto di esempio ha utilizzato un'applicazione Rohde & Schwarz VISA Tester per testare i comandi SCPI.

Dopo aver collegato l'applicazione all'attrezzatura di prova, il primo test consiste nell'emettere una richiesta di identità (IDN?). Questo è un primo passo consigliato, e il comando è interamente gestito dalla libreria SCPI, assicurando che le comunicazioni siano operative e che la libreria sia configurata correttamente. Ciò significa che la risoluzione di eventuali problemi relativi a test che richiedono una risposta da un dispositivo periferico o dall'attrezzatura di prova può presupporre che le comunicazioni e la libreria non siano sospettate nel processo di debug.

Testare le periferiche richiede l'aggiunta di nuovi schemi all'array `scpi_commands` per implementare le funzioni richieste. Le chiamate alla funzione “printf” possono essere incluse per il debug della funzionalità, fornendo un metodo semplice per verificare l'esecuzione del codice.

Nell'esempio, il codice legge lo stato del pulsante utilizzando la funzione “scpi_result_t IO_Btn“ nell'app DAVE precedentemente impostata per il gestore del pulsante con lo stato inviato utilizzando la risposta “SCPI_ResultBool”. Il valore restituito è invertito poiché questo pulsante è un componente a logica negativa.

La funzione di gestione del LED analizza il parametro di stato del pulsante ricevuto e imposta lo stato del LED appropriato. Se non esistono parametri, allora non viene intrapresa alcuna azione per questo esempio. Questo passaggio utilizza la funzione “scpi_result_t IO_Led” per eseguire la sua funzione.

Con il microcontrollore programmato, è possibile testare il codice utilizzando la scheda Console nello strumento DAVE. Ciò dimostrerà la ricezione della connessione e il funzionamento del comando di richiesta di identità.

È possibile verificare lo stato del pulsante inviando una query SCPI e testare la funzionalità osservando che lo stato restituito cambia quando si preme il pulsante.

È possibile testare la funzionalità del LED semplicemente inviando comandi di accensione e spegnimento, osservando lo stato della luce e monitorando lo stato della console.

Con il pulsante e il LED che funzionano correttamente, si ha la base di uno strumento completamente funzionale connesso alla rete. La connessione di una piattaforma di automazione dei test o la scrittura del proprio codice di test consentirà di controllare a distanza lo stato del pulsante e di controllare il LED.

Conclusione

L'articolo mostra come utilizzare l'ambiente di test integrato DAVE con una scheda di sviluppo permetterà di creare e collegare la propria strumentazione di test in rete per integrarla con la strumentazione da banco e automatizzare i test in laboratorio.

Questa guida passo dopo passo è per una dimostrazione di prova del concetto elementare, ma seguire i passaggi e ottenere un sistema di test funzionante ti doterà di tutto ciò di cui hai bisogno per creare i tuoi strumenti di test.

Utilizzeremo i principi che abbiamo esplorato in questo progetto per creare un pratico strumento di test nel prossimo futuro, quindi rimanete sintonizzati per ulteriori sviluppi.