Come posso eseguire il debug di uno schizzo di Arduino?

Ho iniziato a scrivere codice per Arduino molto di recente. E questi bug nel codice mi stanno uccidendo. Poiché non esiste alcun debugger hardware in Arduino, serial.print () è il mio unico ricorso. Quali sono i metodi / pratiche implementati per il debug del codice Arduino?

La modularità è tua amica. Scrivi il tuo ciclo principale per fare la sua cosa chiamando le funzioni, che chiamano funzioni, ..., fino al livello in cui le tue funzioni sarebbero semplici. Inizia con il loop principale e il livello successivo in basso, crea funzioni di stub; vuoto:

function foo(){
    ;
}

o falso:

function read_temperature(){
    return(95);
}

, che non fanno altro che restituire qualunque sia il livello di chiamata necessario affinché sia ​​in grado di continuare. Quando quel livello funziona, passa a un livello inferiore e inizia a compilare un semplice codice che chiama allo stesso modo le funzioni di stub. Disimpegnare gradualmente una funzione alla volta fino a quando non si dispone di un'applicazione funzionante.

Per eseguire il debug di una funzione che restituisce un valore errato o per crearne una senza alcuna influenza dal resto dell'applicazione, è possibile creare un'impalcatura: un semplice schizzo che fornisce semplicemente alla funzione alcuni valori di esempio e all'interno della funzione, stampare i valori dei parametri e alcuni valori intermedi, fino a quando non si ottiene una visione di quale parte della funzione non funziona. Ho anche creato funzioni di simulazione che mi richiedono sul terminale di restituire un valore. (Ovviamente questa tecnica può funzionare solo se il sistema può tollerare la velocità relativamente glaciale di noi umani! Un altro uso per i ponteggi.)

Lo stubbing funziona particolarmente bene per sostituire le funzioni che si interfacciano con l'hardware, permettendoti di iniziare ad aprire l'applicazione prima di immergerti in schede tecniche, problemi di temporizzazione e altre minuzie (come, non avere le parti!) Che potrebbero altrimenti bloccarsi i tuoi progressi.

Parlare di problemi di temporizzazione, attivare o disattivare un pin di uscita in un determinato punto del programma, come l'ingresso e l'uscita da un ISR, ti dà un'onda quadra sul pin di Arduino la cui frequenza o ciclo di lavoro può darti un'idea del tempismo interno del tuo programma. Il modulo I / O porta diretta, ad es.

PORTC ^= 0x01;

, distorcerà i tempi meno che chiamare digitalWrite(). Utile se hai un 'ambito utile o uno dei DMM con la capacità di misurare la frequenza e / o il duty-cycle.

Allo stesso modo, è possibile utilizzare un pin di uscita analogica per inviare un valore numerico al misuratore dall'interno del programma senza disturbare troppo i tempi o gonfiare il codice con le funzioni I / O seriali. Utilizzare qui anche i moduli I / O diretti.

Uso Serial.print () e faccio lampeggiare i LED.

È praticamente tutto ciò che puoi fare.

Inoltre, mi assicuro che il codice sia leggibile e di facile comprensione. Suddividi le cose in semplici passaggi e crea funzioni per ogni passaggio, in modo da poter vedere l'esatta sequenza di eventi.

3 altre tecniche:

• Sviluppa la funzionalità di un programma testando lentamente in ogni fase, in questo modo affronti solo un piccolo insieme di bug alla volta.

• Costruisci il programma attorno a un interprete di comandi in modo da poter lavorare con le sezioni alla volta come qui .

• Espellere in momenti significativi e utilizzare un ambito.

Il plug-in Visual Micro per Visual Studio fornisce Arduino Debug . Include la traccia e l'interruzione del codice sorgente consente inoltre di "guardare" e / o modificare espressioni e variabili.

Passando da strumenti di lusso come ARM o altre piattaforme (AVR, PIC con strumenti decenti), sono d'accordo che le strutture di debug di Arduino sono troppo limitate. Ma è uno strumento di avviamento con ingresso basso.

Serial.print () è tuo amico. Al mio particolare progetto (college), non avevo nessun LED attaccato, quindi lo è Serial.print (). Se voglio verificare se il codice viene eseguito correttamente attraverso le istruzioni, di solito inserisco Serial.print ("A"); , quindi andare su B, C, ecc. o qualcosa del genere nella sezione di cui sto eseguendo il debug. Confronto le lettere di debug con ciò che mi aspetto che dovrebbe fare.

A parte questo, non ci sono punti di interruzione o passi di codice. Arduino non è altro che una scheda con un chip atmega AVR, un bootloader + ambiente di sviluppo e una tonnellata di librerie software. Sfortunatamente, lavorare con un bootloader limita le funzionalità di debug.

Per rendere l'uso serial.printpiù controllato è possibile definire una variabile booleana globale per attivare e disattivare il debug. Tutte le righe di serial.printverranno racchiuse in ifun'istruzione che verrà eseguita solo se il flag di debug è ON. In questo modo puoi lasciare le righe di debug nel codice anche quando hai finito, ma assicurati di impostare il flag di debug su OFF in seguito.

Meglio che direttamente serial.print, utilizzare le macro. Esempio:

#ifdef TRACE1
#define trace1(s) serial.print(s)
#define traceln1(s) serial.println(s)
#else
#define trace1(s)
#define traceln1(s)
#endif

Usalo in questo modo:

function doIt(param1, param2) {
    trace1("->doIt("); trace1("param1: "); trace1(param1); trace1(" param2: "); trace1(param2); traceln1(")");

    ...

    traceln1("<-doIt");
}

Potresti avere diversi livelli di traccia (#ifdef TRACE2 ...)con maggiori dettagli.

E si potrebbe utilizzare la macro "F", (trace1(F("param1"));). La macro "F" impedisce che la stringa utilizzi la quantità estremamente limitata di SRAM.

Lampeggia i LED, stampa cose sulla porta seriale e scrivi ed esegui il debug di piccole sezioni di codice alla volta, a volte solo poche righe.

Ci sono momenti in cui è possibile modulare. Se in C, ad esempio, è possibile sviluppare e testare una funzione di calcolo, ad esempio che non tocca l'hardware su un computer host, un altro processore, avvolgere la funzione con un banco di prova per alimentare gli input e controllare gli output, ecc.

Un altro modo simile potrebbe essere quello di utilizzare un simulatore di set di istruzioni se ne hai accesso a uno (in caso contrario, è un progetto molto educativo e gratificante, dopo averne fatto alcuni puoi sbatterne uno in un weekend o due). Ancora meglio se qualcuno ha un clone Verilog o VHDL del processore ( ad esempio OpenCores ) puoi provare GHDL, Verilator o Icarus Verilog . Potrebbe essere abbastanza vicino da includere le periferiche che ti interessano e puoi ottenere la visibilità del livello del segnale in ciò che sta accadendo all'interno.

Certo, probabilmente non è un clone perfetto, ma potrebbe essere abbastanza buono. Verilator semplifica davvero la creazione di periferiche in C / C ++ in modo da poter simulare qualsiasi cosa abbiate collegato al dispositivo AVR.

Uscita UART e LED lampeggianti e / o linee GPIO lampeggianti e utilizzo di un oscilloscopio o voltmetro. La chiave per non impazzire è scrivere e eseguire il debug di piccole sezioni di codice. È meglio scrivere 10 righe alla volta ed eseguire 100 test rispetto a 1000 righe e provare a eseguire il debug di tutti in un colpo solo. Soprattutto quando si scopre che la maggior parte dei fogli di dati e dei manuali di riferimento dei programmatori per l'hardware non sono sempre corretti. Alcuni hacking sono sempre richiesti.