modelli unit test per il codice microcontrollore C

Question

Anche se ci sono un sacco di framework di unit test che supportano C, sono un po 'perplesso su come scrivere unit test per il codice microcontrollore PIC (nel mio caso, ma credo che la questione è più generale di quello).

La maggior parte del codice scritto per microcontrollori ruota intorno Scrittura dei valori di configurazione e dati di registri, la lettura dei dati in arrivo da registri e rispondere agli eventi di interrupt. Mi chiedo se qualcuno può fornire alcune indicazioni sul modo più efficace per questo.

Answer 1

Si scrive;

"Gran parte del codice scritto per microcontrollori ruota intorno Scrittura dei valori di configurazione e dati di registri, la lettura dei dati in entrata da registri e rispondere agli eventi di interrupt".

Sono d'accordo che questo è spesso il caso, in pratica, ma io in realtà non credo che questa sia una buona cosa, e credo che ripensare le cose un po 'vi aiuterà con i vostri obiettivi di prova.

Forse perché i programmatori di microcontrollori possono toccare con mano l'hardware in qualsiasi momento a loro piace, molti (la maggior parte?) Di loro hanno preso l'abitudine di fare proprio questo, in tutto il loro codice. Spesso questa abitudine è seguito senza discutere, forse perché così tante persone che fanno questo tipo di lavoro sono Straordinari non informatici scienziati di formazione e inclinazione. Lo so, ho iniziato in quel modo me stesso.

Il punto che sto cercando di fare, è che i progetti di microcontrollori possono e devono essere ben progettati come qualsiasi altro progetto software. Una parte molto importante di un buon design è quello di limitare l'accesso hardware per i driver hardware! Compartimentare tutto il codice che scrive registri, risponde a interrupt etc. in moduli che forniscono il resto del software con una bella, pulita, l'accesso astratta all'hardware. Testare i moduli del driver sul bersaglio utilizzando analizzatori logici, oscilloscopi, banchi di prova su misura o qualsiasi altra cosa ha un senso.

Un punto molto importante è che ora il resto del software, si spera che la grande maggioranza di esso, ora è solo il codice C che è possibile eseguire e testare su un sistema host. Sul sistema host i moduli hardware sono spense in un modo che fornisce visibilità in quello che sta facendo il codice sotto test. È possibile utilizzare approcci di unit test tradizionali su questo codice. Questo ha bisogno di alcuni preparati e di lavoro, ma se si sono ben organizzati è possibile creare un sistema riutilizzabile che può applicarsi a tutti i vostri progetti. I benefici potenziali sono enormi. Ho scritto un po 'di più su queste idee qui;

[ http://discuss.joelonsoftware.com/default asp? joel.3.530964.12] [1]

Answer 2

Un approccio per questo potrebbe essere quella di utilizzare un emulatore. Ho lavorato su un emulatore AVR e una delle idee per il suo utilizzo è infatti quello di codice di unit test. L'emulatore implementa la CPU e registri, interrupt e varie periferiche, e (nel mio caso) bytes scritti sul UART emulato andare al stdout regolare dell'emulatore. In questo modo, il codice di unit test può essere eseguito nell'emulatore e scrivere i risultati dei test per la console.

Naturalmente, è anche necessario garantire che l'emulatore è correttamente attuando il comportamento della CPU reale, altrimenti i test di unità in cima che non può essere attendibile.

Answer 3

Scrivi versioni finte delle vostre funzioni di accesso registro / macro. Si noti che questo presuppone che il codice utilizza un set comune di funzioni di accesso registro, e non ad hoc roba come *(volatile int*)0xDEADBEEF = 0xBADF00D ovunque.

Chiama i tuoi gestori di interrupt direttamente dal codice di test (può essere problematico su alcuni architectures¹), un "software interrupt", se disponibile, o da un gestore di interrupt timer, se avete bisogno di eseguire in modo asincrono. Questo può richiedere avvolgendo il codice di abilitazione interrupt / disabilitare funzioni / macro che è possibile mock up.

¹ 8051 viene in mente: almeno con la Keil 8051 compilatore, non è possibile chiamare direttamente le funzioni di interrupt. Ciò ha potuto essere risolto con la C preprocessore però.

Answer 4

C'è forse qualsiasi tipo di modalità di loopback in modo che è possibile utilizzare il controller stesso per generare eventi che è possibile testare contro?