I punti di interruzione sono un ottimo modo per vedere come il compilatore viene eseguito sul tuo codice. Ora la mia domanda è: esiste la possibilità di utilizzare i punti di interruzione quando si esegue il debug del codice?
Come utilizzare i punti di interruzione per il debug
Risposte:
Come indicato nella risposta di Majenko, l'IDE di Arduino non fornisce un meccanismo di breakpoint ma Atmel Studio supporta i breakpoint . [*]
Tuttavia, se si dispone di un interruttore e un LED, è possibile tenere traccia dell'avanzamento del programma in modo da offrire alcuni dei vantaggi dei punti di interruzione. Aggiungete una subroutine, diciamo BPReport(), che tramite l'uscita seriale o un LCD riporta valori di variabili critiche, quindi accende il LED e attende fino a quando l'interruttore non viene premuto e rilasciato, con debounce. Chiama la tua BPReport()routine ovunque tu voglia un breakpoint incondizionato. Per i punti di interruzione condizionali, puoi avere una routine BPReportIf(cond)che chiama BPReport()se condè vera. Se non si desidera eseguire l'output tramite seriale, è possibile utilizzare più LED o un LCD e utilizzare diversi switch se si desidera un controllo di interruzione esterno (ad esempio, condpotrebbe essere un test di uno degli switch extra).
[*] Alcuni debugger hardware modificano il codice scaricato ogni volta che vengono aggiunti, modificati o rimossi i punti di interruzione. Tale utilizzo consumerà la memoria flash più rapidamente rispetto al download occasionale. Se un chip è stato ampiamente utilizzato per tale debug, non utilizzare quel chip in un sistema di produzione.
Sebbene Majenko la sua risposta sia corretta, ci sono alcune altre opzioni.
Per quanto riguarda il debug hardware reale, come affermato da Majenko, direi:
- Installa e usa un IDE reale, come Atmel Studio o il plug-in eclissi arduino chiamato sloeber (sono autore) e
- Utilizzare un debugger hardware completo o hardware che lo abbia a bordo come Arduio zero o hardware utilizzando altre tecnologie di debug come ESP8266 che consente il debug USB
Un'altra opzione di debug di una categoria completamente diversa consiste nell'organizzare il codice in modo tale che la logica decisionale (indipendente dall'hardware) e l'azione (dipendente dall'hardware) siano completamente separate.
Quindi compila il tuo schizzo come programma locale ed esegui il debug della "logica decisionale" sul tuo computer locale. Questo metodo non consente il "debug dell'hardware". Questo metodo consente anche il test dell'unità.
Nota che il tuo computer locale è probabilmente un 32 o 64 bitter e la maggior parte di Arduino ha 8 bitter, il che comporterà differenze nei tipi di dati che sono un ulteriore punto di attenzione quando si utilizza questo metodo.
La libreria Arduino-Debug fornisce un semplice debugger sul target per gli schizzi di Arduino. Il comando di debug viene aggiunto direttamente allo schizzo. Una shell dei comandi di debugger viene avviata su punti di interruzione e asserzioni.
La schermata sopra mostra lo schizzo di esempio eseguito su un Arduino Mega con monitor di output seriale utilizzato dall'applicazione e Serial1 utilizzato per la shell di debugger.
Comandi di debug dello schizzo
- ASSERT (cond) Controllare le condizioni di assert. Se false viene chiamata la shell di debug. Lo schizzo non può continuare.
- BREAKPOINT () Viene chiamata la shell di debug.
- BREAK_IF (cond) La shell di debug viene chiamata se la condizione è vera.
- CHECK_STACK (room) Controlla che ci sia spazio (byte) nello stack. Se false viene chiamata la shell di debug.
- DEBUG_STREAM (dev) Utilizza il dispositivo stream specificato per la sessione di debug. Tipicamente seriale.
- OBSERVE (expr) Stampa l'espressione nel flusso di debug.
- OBSERVE_IF (cond, expr) Stampa l'espressione sul flusso di debug se la condizione è vera.
- REGISTER (var) Registra una variabile per l'accesso dalla shell di debug. Comandi Shell di debug
Comandi Shell di debug
- ? VARIABILE Stampa l'indirizzo e il valore della variabile.
- @VARIABLE Stampa indirizzo variabile puntatore e valore di riferimento.
- backtrace Stampa semplice call-stack.
- comandi Stampa l'elenco dei comandi (vedere anche la guida).
- data Stampa il contenuto dell'area dati, ovvero le variabili globali.
- vai Lasciare la shell di debug e continuare l'esecuzione dello schizzo.
- heap Stampa il contenuto dell'heap, ovvero i dati allocati dinamici.
- help Stampa l'elenco dei comandi.
- memoria Stampa lo stato della memoria.
- esci Interrompi schizzo.
- stack Stampa il contenuto dello stack, ovvero frame di chiamata, argomenti, indirizzi di ritorno.
- variabili Stampa l'elenco delle variabili registrate.
- dove Stampa il file del codice sorgente e la riga in cui è stata chiamata la shell di debug.
Tutti i comandi della shell di debug possono essere abbreviati in comandi a carattere singolo. Si prega di consultare il README per ulteriori dettagli; dettagli di installazione, esempio di schizzo e benchmarking.
1
La libreria donata di Mikael consente di impostare punti di interruzione condizionali, valori delle variabili di stampa, stato della memoria, tracce di chiamata ed esaminare e modificare le variabili in un punto di interruzione. Pro: non ha bisogno di hardware ($$), non è troppo duro con il Flash (come farebbe per impostare e rimuovere i punti di interruzione con un debugger hardware). ....
—
JRobert,
.... Contro: maggiore impatto sullo spazio del codice del programma, un po 'di spazio RAM e possibilmente tempo di esecuzione, se si esamina il codice time-critical; qualche curva di apprendimento per compilare (e successivamente rimuovere) le chiamate in libreria; la necessità di anticipare le posizioni dei punti di interruzione o di ricompilarle quando scopri dove ti servono. I contro non sono una critica al lavoro di Mikael; vengono con questa tecnica.
—
JRobert,
@JRobert Nice riassunto del Pro-Con! Ho cercato di affrontare alcuni dei contro consentendo al debugger di essere personalizzato. Esiste una serie di definizioni che consentiranno alle applicazioni sensibili al footprint di ridurre al minimo la shell di debug. Come ogni debugger per sistemi embedded, è difficile eseguire il debug di codice (continuo) critico nel tempo con punti di interruzione. L'unica alternativa sono i punti di osservazione. Questi potrebbero essere ottimizzati utilizzando un buffer di traccia e rimuovere l'output seriale in codice time-critical.
—
Mikael Patel,