Il Codice di prova per Applicazioni Embedded

Question

Sfondo:

Sto sviluppando una abbastanza grande progetto utilizzando Atmel AVR atmega2560.Questo progetto contiene un sacco di hardware le funzioni di base (7 SPI, 2 I2C, 2 porte RS485 MODBUS, un sacco di Analogici e/O Digitali).Ho sviluppato il "driver" per tutti questi dispositivi che forniscono il principale ciclo di applicazione con un'interfaccia per accedere ai dati richiesti.

Domanda:

Il progetto che sto sviluppando avrà, infine, per soddisfare SIL standard.

Vorrei essere in grado di testare il codice e fornire un buon livello di copertura del codice.Comunque io sono in grado di trovare qualsiasi informazione mi è iniziato come un framework di test dovrebbe essere impostato.

L'idea è che posso avere una suite di test automatizzati che permetterà in futuro di correzioni di bug e nuove funzionalità per essere testato per vedere se si rompono il codice.L'unica cosa è che non riesco a capire come il codice può essere testato su chip.

Ho bisogno di hardware monitor i/O del dispositivo e di emulare i dispositivi collegati esternamente?Tutti i puntatori che possono essere fornite sarebbero molto apprezzati.

- Steve

Answer 1

Questa è una domanda molto buona - una preoccupazione comune per gli sviluppatori embedded. Purtroppo, la maggior parte gli sviluppatori incorporati non sono così preoccupati come siete e testare solo il codice su hardware reale. Ma, come un'altra risposta ha sottolineato, questo può sostanzialmente testare solo la funzionalità nominale del codice e non i casi d'angolo / errore.

Non esiste una soluzione unica e semplice a questo problema. Alcuni esistono le linee guida e le tecniche, tuttavia, per fare un lavoro relativamente buono.

In primo luogo, separare il codice in strati. Uno strato dovrebbe essere "hardware agnostic" - vale a dire chiamate di funzione . Non chiedere all'utente di scrivere in HW registra direttamente. Gli altri (inferiore) offerte Layer HW. Questo strato può essere "deriso" al fine di verificare il livello superiore. Il livello più basso non può essere veramente messa alla prova senza l'HW, ma non sta andando a cambiare spesso e ha bisogno di integrazione HW profonda, quindi non è un problema.

Un "test harness" sarà tutto vostro di alto livello HW codice agnostico con un livello più basso "falso" specificamente per il test. Questo può simulare i dispositivi HW per la funzionalità corretta e non corretta e quindi consentono di eseguire test automatizzati sul PC.

Answer 2

Non eseguire unit test su o contro l'hardware reale. deridere sempre le interfacce di I / O. In caso contrario, non è possibile simulare le condizioni di errore e, soprattutto, non si può fare affidamento sul test per avere successo.

Quindi, ciò che è necessario è quello di dividere la vostra applicazione in vari pezzi che è possibile testare in modo indipendente. Simulator (o finto) tutto l'hardware di cui avete bisogno per questi test e li esegue sul vostro PC di sviluppo.

Questo dovrebbe coprire la maggior parte del codice e ti lascia con i driver. Provate a fare il maggior numero di codice del driver il più possibile il lavoro senza l'hardware. Per il resto, si dovrà trovare un modo per rendere il codice eseguito su hardware. Questo di solito significa che è necessario creare un banco di prova con dispositivi esterni che rispondono ai segnali, ecc Dal momento che questa è fragile (come in "i test non possono fare questo lavoro automaticamente"), è necessario eseguire questi test manualmente dopo aver preparato l'hardware.

Answer 3

Vectorcast è uno strumento commerciale per eseguire unit test sull'hardware con copertura del codice.

Answer 4

Hai un connettore JTAG? Si può essere in grado di utilizzare JTAG per simulare le condizioni di errore sul chip.

Answer 5

Mi piace separare i compiti.Per esempio, quando ho fatto un buffer circolare per il mio Atmel AVR l'ho scritto tutto in Code::Blocks e compilato con il normale compilatore GCC invece di AVR compilatore GCC, poi ho creato una unità di test.Ho usato uno speciale file di intestazione per fornire il corretto tipi di dati che ho voluto lavorare con (uint8_t per esempio).Ho trovato errori con i test, li fissò, poi ha preso il codice fisso su di AVR Studio e integrato.Dopo di che ho usato ha scritto funzioni di supporto e ISRs per adattare la dimensione del buffer e utile codice (vale a dire, pop un byte di disattivare il buffer, spingere in UART dati di output register, di aggiungere una stringa costante per il buffer per una funzione printf, ecc).Poi ho usato l'AVR simulatore per assicurarsi che il mio Isr e funzioni sono stati chiamati e che i dati hanno mostrato fino a registri.Dopo che ho programmato sul chip e ha funzionato perfettamente.

Preferisco di gran lunga la funzionalità di debug di Code::Blocks rispetto a AVR Studio in modo da utilizzare l'approccio sopra descritto, ogni volta che posso.Quando io non sono solito trattare solo hardware.Per esempio ho un timer che genera automaticamente un onda quadra.Il meglio che ho potuto fare è stato vedere che il pin po ' era twiddled nel simulatore.Dopo di che ho dovuto agganciare un ambito di applicazione e assicurarsi.

Mi piace usare un multi-livello di approccio quando il debug di problemi.Per esempio con l'orologio, il primo strato è 'Messo una sonda sul pin di clock e vedere se c'è segnale c'e'.Se non, sonda pin su uC e cercare il segnale.Allora, ho codificato un interfaccia di debug in uno dei miei UARTs dove posso guardare specifici valori di registro e assicurarsi che essi sono ciò che si suppone di essere.Quindi, se non funziona, il passo successivo è 'richiamare il valore di registro e assicurarsi che sia corretto.'

Provate a pensare davanti a quattro passi o così ogni volta che siete pianificazione di debug.Ci dovrebbe essere +5V qui, ma se non c'è?Scrivere in debug interfaccia un modo per passare il pin e vedere se cambia.Che cosa se non funziona?Fare qualcosa di diverso, etc etc etc.Si arriva a un punto in cui si esegue in 'NON ho IDEA del PERCHÉ QUESTO DANG COSA NON FUNZIONA!!!!' ma spero che possiate capire il motivo di anticipo.