Lo scopo di questo articolo è di dare la possibilità ai microcontrollisti di avere un sistema per sviluppare su microcontrollori basati su ARM, nel particolare i Cortex-M3. Seguendo il forum da qualche anno non ho potuto notare il progresso di alcuni utenti che, partiti dai micro più semplici, hanno intrapreso un percorso di conoscenza che li ha portati a diventare dei microcontrollisti con "le palle quadre". Sono sicuro che ci sono molti talenti e sono altresì convinto che offrire degli strumenti per fare in modo che queste potenzialità possano concretizzarsi sia una cosa buona, un qualcosa che valga la pena fare.

32 bit

I microcontrollori a 32bit sono il futuro. E' inutile girarci intorno, prima o poi lo sperimentatore evoluto dovrà fare il grande balzo e passare dagli 8/16bit ai 32 bit. Per chi ha sempre e solo lavorato con micro ad 8 o 16bit passare ai 32bit vuol dire scoprire un mondo nuovo, salire ad un livello di prestazioni non paragonabile a gli altri micro. Vuol dire rendersi conto di lavorare non con un microcontrollore ma con un vero e proprio computer. Inutile dire che una volta che ci si è impratichiti con questi oggetti sarà molto ma molto difficile riprendere ad utilizzare gli 8bit, proprio perché ci si abitua a macchine serie al punto che gli 8bit vengono poi visti e considerati poco più che giocattoli.

Già oggi si possono acquistare micro a 32bit pagandoli di meno che gli 8bit e moltissimi questi oggetti fanno parte della famiglia degli ARM. Sono potenti, veloci, costano poco, sono diffusissimi e consumano pochissimo. Io uso i Cortex-M3 per lavoro e devo ammettere che, dopo un inizio abbastanza impegnativo, ho avuto modo di sviluppare i miei prodotti con facilità grazie alle loro prestazioni. Lavorare con questi bestioni è come utilizzare un motore di una Ferrari depotenziato e venduto al prezzo di un motore da decespugliatori. Il paragone lo trovo particolarmente calzante perché lavorare con un motore del genere non è il massimo della semplicità ma avere 200 CV a disposizione al prezzo di un tosaerba permette di fare cose impensabili.
Nella fattispecie i Cortex-M3 sono l' evoluzione dell' ARM7TDMI che, a sua volta, è la versione depotenziata del ARM9, quello che si usa negli smartphone e nei navigatori, per intenderci. Il problema è che questi oggetti sono ancora orientati verso un utilizzo professionale e quindi lo sperimentatore che decide di usarli e "fare il balzo" incontra diversi ostacoli, che poi sono sostanzialmente due:

• La complessità. I 32bit sono oggetti complicati. Questo è un aspetto risolvibile con lo studio, quindi è solo una questione di tempo e di impegno.
• I costi di sviluppo. Allo stato dell' arte questi oggetti sono ancora confinati prevalentemente nell' ambito professionale. I sistemi di sviluppo seri come quello della IAR o della Keil costano cifre che solo i professionisti possono spendere. Si parla di diverse migliaia di euro.

Se per il primo aspetto è sufficiente lo studio, per il secondo punto i soldi, e ne servono tanti. E' anche vero che esistono sistemi di sviluppo più a buon mercato dei due che ho menzionato prima, ma comunque si tratta di spendere soldi. E' anche vero che alcune case offrono il sistema di sviluppo gratis, ma è anche vero che questi sono specifici per i loro micro basati su architettura ARM. La cosa migliore sarebbe avere un sistema che dia la possibilità di sviluppare programmi per qualsiasi micro con architettura ARM.
Ho pensato che sarebbe stato bello riuscire a mettere insieme o trovare in giro un sistema di sviluppo valido per dare la possibilità allo sperimentatore evoluto (ma anche al professionista che non conosce ancora questi oggetti e vorrebbe provarli) di avere uno strumento valido per fare le esperienze senza dovere vendere l' automobile o accendere un mutuo in banca e, grazie anche all' interessamento di altri utenti di EY, penso di avere raggiunto lo scopo.

Perché il Cortex-M3

Ecco, qui vorrei raccontare la mia esperienza, il perché ho adottato questi micro per i miei progetti.
Dovevo sviluppare un' apparecchiatura che avrei dovuto poi produrre in serie. Quindi era necessario fare un progetto che costasse poco e che non dovesse mettermi in croce per lo sviluppo. Come al solito ero in cerca dell' alta moda a mille lire al pezzo.
Per il progetto sarebbe bastato un PIC18 o, in alternativa, un PIC24 ma per esperienza sapevo che sarebbero stati, come dire, ecco "tirati per il collo". Avrei dovuto anche questa volta fare una serie di salti mortali per fare in modo di far funzionare tutta la baracca. Per caso mi sono imbattuto negli STM32, in particolare negli STM32F100. La prima cosa che ha attirato la mia attenzione è stato ovviamente il prezzo, costano pochissimo. E' vero che questi micro lavorano con una frequenza di clock a 24MHz (un terzo dei loro famigliari) ma è anche vero che, a parità di prezzo se comparati a micro ad 8 o 16 bit, la bilancia delle prestazioni pende totalmente a favore del STM32. In buona sostanza ho capito che se avessi utilizzato questo micro non solo avrei risparmiato ma avrei lavorato "in scioltezza", senza problemi di prestazioni o di memoria, impiegandoci meno tempo nella stesura del programma e tenendo per me una certa "riserva di potenza" che prima o poi mi sarebbe stata utile.
Mi sono messo alla ricerca di un sistema di sviluppo per poter fare alcune prove a mi sono imbattuto nel True Studio della Atollic (basato su gcc). La versione light era allettante perché non poneva limiti di codice ma, di contro, non permetteva il debugging. Ho pensato di non aver problemi nello scegliere questa soluzione. In effetti la prima versione l' ho realizzata con questo sistema di sviluppo e funzionava bene! Sono poi passato ad un altro sistema di sviluppo nel momento in cui ho capito che avrei utilizzato questi micro per altri progetti, e così è stato.
La versione che ho utilizzato purtroppo non è più disponibile. La Atollic ci ha ripensato ed oggi la versione light ha la limitazione a 32KB di codice, e la versione a pagamento anche se costa meno di altri sistemi, ha sempre un costo non affrontabile da parte di un hobbista.

Il sistema di sviluppo

Fra quelli che ho sperimentato emIDE penso che sia il migliore per lavorare seriamente. Per "seriamente" intendo dire non solo scrivere programmi che funzionano ma anche avere un valido supporto per il debugging. Detto fra di noi del debugger si potrebbe anche fare a meno ma ci sono situazioni in cui il debugger si rivela essere l' ultima carta da giocare. Il classico esempio è il programma che si pianta senza apparente motivo visibile, magari per una eccezione di quelle brutte (ad esempio un problema sullo stack), un problema che non si riesce ad individuare alla prima, seconda, terza analisi. A quel punto il debugger è d' obbligo perché è l' unico sistema per riuscire ad individuare il baco in tempi umani.
Questo sistema di sviluppo, anche se è limitato (per adesso) per l' uso con il debugger J-link, permette di fare un ottimo debug.

Il J-link

E' un debugger prodotto dalla Segger. Direi che è uno dei più diffusi. Dal J-Link derivano debugger come il SAM-ICE della Atmel (che però funziona solo con gli Atmel), come l' emulatore della IAR e molti altri, compresi un mare di cloni. Se è vero che il J-Link non è un oggetto a buon mercato (il più piccolo costa intorno ai 300$) è anche vero che la Segger ha messo in commercio una versione didattica, Il J-Link EDU che si compra con una cinquantina di euro. Quando lo si acquista si deve fare promessa solenne di utilizzarlo solo per scopi didattici e mai per scopi commerciali e questo potrebbe essere una limitazione per il professionista, ma è anche vero che, una volta messo su il sistema, il professionista può benissimo spendere 300$ per comprare quello ad uso commerciale ed essere contento di spendere così poco.
Il J-Link viene utilizzato per il debug tramite il GDB server. Sono abbastanza ignorante in queste cose ma da quello che ho potuto capire il sistema funziona in questo modo: insieme al J-Link viene fornito un software che fa da interfaccia fra il debugger fisico ed il sistema di sviluppo: Il sistema di sviluppo comunica con questa interfaccia tramite un suo plug-in. Il risultato è che si hanno due software che girano contemporaneamente: Il sistema di sviluppo e questo server e che insieme permettono di fare il debug.

Installiamo il sistema

Ovviamente bisogna scaricare emIDE e lo si può fare a questo indirizzo. Esistono due versioni per winzozz, e precisamente quella portabile e quella sotto forma di installer. Come prima prova ho scaricato quella portabile con cui ci ho lavorato fino a quando ho avuto la certezza di avere uno strumento valido, in seguito ho scaricato l' installer ed ho usato quest' ultimo.
Poi si ha bisogno del J-Link EDU. Lo si trova più o meno ovunque fra i distributori di componenti elettronici. Io l' ho comprato da Digikey. Il software per l' oggetto lo si scarica dal sito della Segger a questo indirizzo. All' atto dello scaricamento è richiesto il numero di serie. Giusto per informazione io di questi J-Link EDU ne ho più di uno perché l' ho provato su tanti micro con architettura ARM e funziona con tutti. Mi sono voluto parare il c... ehm ... ho pensato di dotarmi di più di un debugger (come riserva di sopravvivenza) per mettermi al riparo ed avere, in caso di guerra, morte e disperazione, almeno un paio di dispositivi validi per poter ricostruire un futuro dalle macerie, ecco. :)
Il sistema di sviluppo contiene già la toolchain YAGARTO e quindi, una volta installati questi due software, c'è tutto quello che serve per iniziare a ravanare su questi micro.
Tuttavia suggerisco di scaricarsi anche l' ultima versione di gcc per ARM. La mia l' ho scaricata a questo indirizzo, ho scaricato la versione zip perché ho poi cambiato i vari compilatori/assembler/linker e compagnia cantate in modo da usare quelli più recenti. Il GDB server invece deve essere quello suo, quello di default dell' IDE. Ho provato a cambiarlo ma non funziona (misteri dei PC) e quindi sono tornato a quello precedente.

Il micro di prova

Per fare le prove ho utilizzato una scheda di sviluppo fatta da me che monta un STM32. La scelta del STM32 è ovvia perché io lavoro con questi micro e quindi so già dove andare a parare. Poi, per carità, si può benissimo utilizzare un altro micro ed io ho semplicemente scelto quello che già conosco e che mi permette di andare sul sicuro. In ogni caso quelli della ST sono i Cortex che costano di meno ed hanno una bella libreria per l' utilizzo delle periferiche.

Primo test del sistema

Dobbiamo ora accertarci che il sistema funzioni correttamente. Per fare questo dobbiamo creare un progetto minimo, un qualsiasi cosa per averr modo di verficare se la toolchain funziona correttamente e se riusciamo a fare il debug tramite il J-Link. Apriamo quindi emIDE e, dopo le varie domande di rito che fa al primissimo avvio, ci troveremo la pagina iniziale e clicchiamo su Create a new project.

startPage.jpg

Compare la finestra di dialogo dalla quale si possono selezionare diversi modelli o semplicemente lo scheletro di un progetti, il minimo sindacale per far qualcosa di funzionante.

wizard1.jpg

Noi clicchiamo su Embedded application e poi sul tasto Go.
La finestra di dialogo che compare dopo è assolutamente inutile, comunica che si sta per creare un progetto tramite il wizad. quindi premiamo Next e procediamo.
Compare poi la richiesta del nome del progetto e della cartella in cui crearlo. Il nome e la cartella. in questa fase, possono essere qualsiasi. In questo esempio, con uno slancio di grande fantasia, imposto "Prova" come nome del progetto, creo una cartella sul desktop chiamata "Prova", la seleziono e proseguo oltre.

nomeProgetto.jpg

Compare la finestra per la scelta del compilatore.

sceltaCompilatore.jpg

Teniamo tutto così com' è e andiamo avanti.
E' arrivato il momento di scegliere il microcontrollore, o meglio, il fabbricante. Selezioniamo ST e procediamo.
Finalmente arriviamo al momento di scegliere il micro. Scegliamo STM32F103RC (o meglio io seleziono questo perché con questo ho realizzato la mia schedina) ed andiamo avanti.
Al passo successivo vengono richieste le impostazioni per la grandezza dello stack e dell' heap.

stackHeap.jpg

Non cambiamo niente e premiamo "Next"
La finestra seguente ci informa che il progetto è stato creato. Premiamo Finish ed abbiamo il nostro progetto pronto. Ma non è ancora finita. Viene infatti visualizzata una finestra con le opzioni del progetto.

projOptions.jpg

Selezioniamo la scheda Debugger, quella più a destra e ci compare la selezione del debugger.

jlinkSelect.jpg

main.jpg

Ora vediamo se tutto quello che abbiamo fatto fin' ora è giusto quindi procediamo in questo modo:

• Verifichiamo che il build target (si trova nella toolbar in alto, proprio sopra la finestra dell' editor) sia impostato su Debug.
• Dal menù selezioniamo Build->Build oppure premiamo il tasto F7- Nella finestra Build Log in basso, sotto l' editor, vedremo tutto il ciclo di compilazione. Se termina senza errori vuol dire che la toolchain funziona alla perfezione.
• Assicuriamoci che la sceda sia alimentata e, ovviamente, che sia collegata al J-Link.
• Anche se emIDE può far partire lui il GDB serve del J-Link consiglio vivamente di farlo partire prima di chiamare il debugger. Quindi selezioniamo del menu dei programmi nella cartella Segger l' applicazione J-LINK GDB server. Compare la finestra del GDB server. Se questo è il primo avvio della giornata compare anche un' altra finestra che ci ricorda che il J-Link EDU serve solo per scopi didattici e tutta la manfrina che ne consegue. Spuntiamo la casella "Accept", andiamo avati e per tutto il giorno non avremo ulteriori rotture di scatole. Se la scheda è correttamente alimentata e le connessioni del J-Link sono corrette ci comparirà quest' altra finestra che lasciamo aperta (se la chiudiamo non facciamo nessun debug. E' importante che questa rimanga sempre attiva!

GDBserver.jpg

• a questo punto apriamo nell' editor il file main.c che è contenuto nella cartella Src come illustrato nella foto seguente.

main.jpg

• Quindi facciamo partire il debugger premendo F5 oppure premendo il triangolino blu a fiano del build target, oppure da munù Debug->Start/Continue

Se ci compare questa schermata

debugOn.jpg

Allora vuol dire che il plugin del J-Link si è connesso con successo al GDB server. Siamo ad un passo dalla fine!
Ed ora la prova del nove. Premiamo su questo simbolo nella toolbar

debuggerStep.jpg

Se ad ogni pressione di tale simbolo vediamo che la barra gialla visualizzata nell' editor avanza di un passo vuol dire una solo cosa: il sistema è installato correttamente e possiamo iniziare a lavorare.

Note importanti

Probabilmente la mia imbranataggine con i PC mi rende la vita difficile. Ho scritto prima che è meglio chiamare il GDB server di J-Link prima di fare partire il debug perché a volte, e non ne ho ancora capito il motivo (succede di solito alla prima sessione di debug della giornata) il plugin non riesce a comunicare. Il più delle volte è perché ci sono due istanze del software del J-Link aperte contemporaneamente e, visto che le finestre sono perfettamente sovrapposte, non me ne accorgo. In ogni caso, dopo qualche smanettamento tutto si mette a funzionare alla perfezione. Ripeto: non ho ancora capito bene questo meccanismo e perché di tanto in tanto mi fa girare le scatole. Mi riprometto, quando avrò individuato bene quale operazione (sbagliata) faccio, di riprendere questo articolo e scriverci un addendum di spiegazione in modo da non dover più fare il trafficone. In ogni caso, al di la di qualche eventuale mossa sbagliata, ho potuto verificare il buon funzionamento di tutta la baracca su più PC, quindi mi sento di dire che questo non è affatto un problema e che il sistema in se è molto affidabile.

Si può iniziare a lavorare?

Ni, nel senso che si possono sviluppare programmi che non utilizzano le interrupt. Il fatto è che il file di startup così com'è è incompleto, contiene solo i vettori minimi richiesti dal core. Questo vuol dire che si possono fare prove ed incominciare ad impratichirsi sia con il sistema di sviluppo che con il micro stesso per valutarne le prestazioni e/o le possibilità.

Prossimamente su questi schermi

Avrei voluto fare un unico articolo che comprendesse tutto, e cioè il progetto di base basato sulle librerie standard della ST (molto ben fatte e molto utili soprattutto all' inizio) ed uno schema per un hardware su cui fare le prove. Questo avrebbe voluto dire posticipare l' uscita dell' articolo. Ho pensato che alcuni utenti (soprattutto quelli già un po' smaliziati) avrebbero preferito avere subito a disposizione lo strumento.
Inoltre sto passando un periodo problematico e quindi rischiavo di mandare la cosa per le lunghe.
Buona sperimentazione!