Siamo alla fine di questo piccolo viaggio alla scoperta della STM32 Discovery. Nei primi tre articoli (1°, 2° e 3°) abbiamo tentato di abbracciare quanti più argomenti possibili, cercando di ingolosire gli sviluppatori. In questo appuntamento impareremo ad usare le modalità di debug messe a disposizione da CoIDE ed da STMSTudio, un tool di debug più performante. Infine come sempre chiuderemo con un piccolo esempio pratico realizzando un piccolo progetto di domotica. Soddisfatti dal successo ottenuto nei primi tre articoli, segno di una community viva ed attenta, speriamo che questo non sia un arrivederci ma l’inizio di un proficuo confronto su questo argomento.
DEBUG
Leggendo la definizione di Wikipedia: “Il debugging, in informatica indica l’attività che consiste nell'individuazione da parte del programmatore della porzione di software affetta da errore (bug) rilevata nei software a seguito dell’utilizzo del programma”, si capisce molto bene che all'aumentare della mole di codice scritto o della complessità di questo, anche gli utenti più esperti spesso hanno bisogno di un strumento che li aiuti a capire perché il programma che hanno scritto, fa di testa propria. Ovviamente, come in quasi tutte le cose della vita, l’esperienza è l’elemento fondamentale quando si cerca un errore, ma quest’ultima nel campo informatico indica soltanto dove andare a cercare, poi serve una lente per guardare, ovvero un programma di debug. Questo principalmente è lo scopo di tali strumenti, che emulano o eseguono pezzi di codice definiti dal programmatore, dove si presume si sia nascosto l’errore, mostrando i valori delle variabili, le chiamate delle funzioni e tutto ciò che può tornare utile alla perfetta comprensione del programma.
Anche in questo ambito le Discovery si mostrano preparate montando già a bordo, insieme al programmatore, tutto l’hardware necessario per il debug, ovvero il debugger. Oltre all'hardware per il debug ci serve un software capace di svolgere tale compito; l'IDE di sviluppo utilizzata fino ad ora (CoIDE) mette a disposizione del programmatore una modalità di debug capace di analizzare la sequenza di flusso delle operazioni e lo stato della memoria interna del microcontrollore.
Volendo semplificare la spiegazione partiamo dall'analisi di un caso pratico. Prendiamo ad esempio il progettino mostrato nel primo articolo: questo, infatti, ha un struttura semplice che si adatta perfettamente a questo primo tentativo di debug. Nello specifico, veniva mostrato come gestire l’accensione e lo spegnimento temporizzato dei LEDs integrati della scheda sfruttando un timer: quindi riprogrammando la Discovery con quel codice dovremmo vedere i quattro led lampeggiare con frequenze diverse. Per avviare la modalità di debug non bisogna far altro che cliccare sulla relativa icona presente nell'interfaccia utente di CoIDE, come evidenziato in figura 1.
Figura 1 - Tasto per avviare la modalità di Debug
Una volta avviato, il debug rimarrà in attesa di comandi alla prima riga di codice all’interno del main: spetta all’utente registrare, avviare, mettere in pausa o eseguire le singole istruzioni utilizzando i nuovi bottoni apparsi nella toolbox dell’interfaccia utente (figura 2).
Figura 2 - Comandi della modalità di Debug
Proviamo quindi a verificare il flusso di esecuzione. Ricordando che il programma gestisce i LED tramite un’interruzione generata da un timer ogni 500 ms, mettiamo un breakpoint all’interno della relativa callback: ovvero indichiamo al debug il punto esatto del programma dove vogliamo fermarci. Facendo un doppio click accanto al numero di riga, apparirà accanto a questa un pallino di colore rosso che indicherà visivamente la presenza del breakpoint. Premendo il bottone “play”, il programma riprenderà la sua esecuzione fermandosi al breakpoint che abbiamo settato. Fin qui abbiamo appurato che il debug ferma l’esecuzione del programma nel momento in cui arriva al breakpoint prestabilito; e che inoltre, nel nostro caso specifico, la callback viene correttamente chiamata, altrimenti il debug avrebbe continuato ad eseguire il programma, in quanto non avrebbe incontrato breakpoint sulla sua strada. Ma il fatto che la callback venga richiamata non necessariamente implica che il programma si stia comportando come voluto. Una maggiore conferma potremmo averla dai valori assunti dalle variabili in gioco. A tal proposito, un buon programma di debug ci offre una finestra nella memoria del processore, mostrandoci appunto i valori correnti (riferite al punto di breakpoint) delle variabili del programma. Nella figura 3, ad esempio, vengono riportati i valori relativi ai quattro LED ottenuti nel nostro caso. [...]
ATTENZIONE: quello che hai appena letto è solo un estratto, l'Articolo Tecnico completo è composto da ben 4999 parole ed è riservato agli ABBONATI. Con l'Abbonamento avrai anche accesso a tutti gli altri Articoli Tecnici che potrai leggere in formato PDF per un anno. ABBONATI ORA, è semplice e sicuro.
Interessante serie sulla STM32 che ha messo in risalto le principali caratteristiche con ottime applicazioni. Nulla vieta di sostituire il sensore pir con uno a micronde.
Grazie per l’interesse.
Sulla STM32F4 si potrebbe dire ancora molto: studio e tempo permettendo, ci sono altre interessanti features da approfondire…. Work in progress ……
Ho seguito con molto interesse questo corso ed a tal proposito vorrei chiedere un proseguimento con altri progetti sull’utilizzo delle ulteriori periferiche del microcontrollore nello specifico sarei interessato ad apprendere la comunicazione can-bus magari facendo una piccola rete di schede discovery che comunicano tra loro avendo come discriminante ID differenti