Per un appassionato di informatica, di elettronica e, in generale, di tecnologia, il mondo dei microcontrollori presenta aspetti molto affascinanti. Esso ne incorpora molti temi differenti, che offrono ulteriori opportunità per allargarsi verso altri, potenzialmente infiniti, orizzonti del mondo reale. Oggi vorrei parlarvi di un tema importantissimo che è forse la principale ragione d’essere di Elettronica Open Source: quello didattico. I giovani, specialmente gli studenti di scuole e di facoltà non tecniche, spesso si relazionano con il mondo digitale senza una vera consapevolezza dei suoi reali principi e meccanismi di funzionamento. Per la loro pervasività ed estensione, l’elettronica e l’informatica non possono essere conosciute nella loro interezza, ma, apprendendone le basi, nulla ci sarà poi precluso se vorremo approfondirle. Per […]
ATTENZIONE: quello che hai appena letto è solo un estratto, l'Articolo Tecnico completo è composto da ben 3063 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.
Ti potrebbe interessare anche:
Scegliere la giusta antenna per le applicazioni IoT
Progetto di un dispositivo di controllo di un accesso di sicurezza con RFID e Arduino – Parte 2
Algoritmi di apprendimento automatico per il riconoscimento dei raggi gamma
Microchip semplifica la sicurezza IoT hardware-based con soluzioni di pre-provisioning
La tecnologia blockchain
Ciao Stefano.
Ottimo articolo introduttivo, per quanto riguarda la scheda, un peccato che le porte funzionino a 3,3V, se fossero state a 5V avrebbero beneficiato della moltitudine di shield già disponibili per Arduino.
La diversa disposizione dei pin si può aggirare con una sorta di adattatore.
Fortunatamente gli ultimo sensori/moduli possono funzionare con un range di alimentazione allargato dai 3,3V ai 5V.
Per quanto riguarda il suo utilizzo, attendiamo magari un tuo prossimo articolo con qualche utilizzo della scheda!
Ciao Adri,
ti ringrazio per l’apprezzamento. In verità, il fatto che le porte (come del resto tutta la circuiteria) vadano a 3.3V lo ritengo assolutamente un pregio. Intanto quella è la tensione standard nell’embedded moderno, inoltre ciò è molto importante in termini di bassi consumi, e poi non dimenticarti dell’alimentazione a batteria con LiPo ma anche con due ministilo. Pensa poi al fatto che il microcontrollore può lavorare a tensioni ancora più basse (anche sotto ai 2V abbassando la velocità di clock e non dovendo scrivere sulla Flash). Quanto al discorso degli Shield, direi che la questione è un poco sopravvalutata, infatti la gran parte dei progetti richiedono comunque una breadboard e una buona parte dei moduli che poi vengono montati sugli Shield sono disponibili separatamente a costi ben inferiori (pensa, per esempio alla possibilità di interfacciare un modulo ESP8266 da una manciata di Euro, per avere il WiFi. Concependo i circuiti separatamente è anche possibile sfruttare al meglio le porte che altrimenti potrebbero essere vincolate dalla scelta effettuata dai progettisti degli Shield. Tieni poi presente che in casa Texas esistono i Boosterpack (anche di terze parti). Per il mondo Grove, inoltre, è appena uscito questo:
http://www.seeedstudio.com/depot/Grove-Base-BoosterPack-p-2177.html?cPath=122_161
http://www.seeedstudio.com/wiki/Grove_Base_BoosterPack
Ciao Stefano,
Ottimo articolo, complimenti.
Hai ragione quando affermi dicendo “esercitatevi molto sull’aritmetica binaria”.
La programmazione a oggetti ha dei limiti con l’interazione hardware; molte volte per raffinare un progetto, dal punto di vista della programmazione, necessità una buona conoscenza anche dell’Assembler.
Dalle foto mi è apparso di capire che la porta USB non è nativa ha un convertitore USB/Seriale, confermi?
Ernesto,
ti ringrazio. C è il linguaggio di alto livello d’elezione nell’embedded – perlomeno nella programmazione di apparati senza sistema operativo – proprio perché ti permette di fare (quasi) tutto quello che, si può fare in Assembler (quindi in linguaggio macchina), mantenendo il pieno controllo e soprattutto l’accesso diretto e granulare alla memoria. In questa classe di dispositivi, poi, non ci si trova di fronte a progetti mastodontici, che richiedano un lavoro organizzato di Team molto vasti, per cui molte delle ragioni d’essere della programmazione ad oggetti e dell’Overhead ad essa associato non hanno senso. L’assenza di un sistema operativo implica anche meno problemi riguardo alla protezione della memoria e quindi dei danni che si possono fare con codice difettoso (penso ai segfault, per esempio), però comunque è necessario prestare attenzione. L’ultima osservazione è che un approccio come quello suggerito nell’articolo permette anche di avvicinarsi all’Assembler partendo da C, e non viceversa come verrebbe logicamente spontaneo. Scrivere qualche riga di codice e vedere come viene compilata e riportata in Assembler nel riquadro accanto dell’IDE ha un valore didattico enorme.
Per quanto riguarda la tua domanda sull’USB, la interpreto nel senso che il microcontrollore in se stesso non prevede internamente una gestione diretta dell’USB. Non è, ad esempio, come l’Atmel ATmega32u4 de3lla Arduino Leonardo, ma come con la Uno e il suo ATmega328, necessita di un dispositivo esterno. Nel caso dei Launchpad di Texas, tuttavia, questo stadio assolve, oltre al ruolo di interfaccia USB client e di seriale virtuale (accessibile da un terminale, tipo il Serial Monitor di Arduino, presente anche in Energia), anche quello di emulatore/debugger e, in alcuni casi, anche di supportare delle classi USB come device (CDC, HID, MSC), come nel caso del MSP430F5529 USB LaunchPad Evaluation Kit:
http://www.ti.com/tool/msp-exp430f5529lp
Ernesto,
rileggendo la mia risposta, mi sono reso conto di non essermi forse spiegato bene, poiché mi riferivo alla foto del Launchpad MSP430G22553, cioè l’entry-level. Volevo precisare che l’altro Launchpad che ho citato nel commento, cioè quello con l’MSP430F5529 (che non ho invece menzionato nell’articolo), ha un MCU che supporta l’USB nativamente anche a livello fisico (PHY) nel senso che intendi tu, un po’ come nel caso dell’Atmel 32u4 citato nel commento, per cui è indicato per programmare l’USB e le sue varie classi, per progettare device che comunicano con questa interfaccia. A questo riguardo vorrei ribadire che, essendo l’MSP430 una famiglia di microcontrollori vastissima, è possibile trovare all’interno della sua gamma il Device con la configurazione e le periferiche di cui uno ha bisogno, non cambiando invece il Core. Ovviamente i Launchpad, che sono schede di sviluppo per i microcontrollori stessi, non montano tutte le possibili varianti. E’ però possibile acquistare delle Board con zoccoli ZIF speciali, che permettono di sviluppare professionalmente sugli MCU in base al loro Packaging (ma che esulano dagli scopi di questo articolo) con l’ausilio di programmatori / debugger esterni. Scusami per la confusione…
Quest’articolo mi ha incuriosito, ho appena ordinato un Launchpad MSP340G2 (ha un costo notevolmente basso) per provare ha realizzare un nuovo generatore di frequenza. Una cosa che ho notato è l’assenza del quarzo su board, probabilmente è dovuta per scegliere il tipo di MSP340 da utilizzare; peccato che per la versione PDIP il clock max è 16Mhz.
Ernesto,
in verità il motivo principale della mancanza del quarzo è quello di non obbligarti ad occupare i PIN dello stesso con uno di frequenza specifica (o per far passare un clock digitale da un’altra fonte per sincronizzarsi) e anche per poterli utilizzare come GPIO (o entrata/uscita di uno dei Timer), Se per il clock ausiliario non hai bisogno di una frequenza molto precisa (e quindi non variabile, per esempio con la temperatura), anche per non consumare inutilmente corrente (come sottolineato nell’articolo, l’MSP430 è stato progettato in ottica Low-Power estrema) è presente un oscillatore interno a bassa velocità (e quindi facilmente utilizzabile con i registri a 16-bit), chiamato VLO (Very Low Oscillator). Esso opera a frequenze nell’intorno dei 12Khz (a temperature normali), ma ha un Range di variabilità molto più ampio di un quarzo, (imprecisione che, però, non importa in alcune applicazioni, e che comunque può essere tarata a Runtime ogni volta che vuoi, con una semplice libreria fornita da TI che lo confronta col clock principale, pre-tarato in fabbrica a 16, 12, 8 e 1Mhz). Normalmente la frequenza più usata dagli Hobbyisti è quella da 32768 Hz (potenza di 2, così puoi dividere facilmente col bit-shift e ricavare un Real-Time-Clock molto preciso), il cui quarzo comunque TI fornisce nella scatola del Launchpad G22553 e che puoi saldare o meno. Diciamo che, in linea con una filosofia più consapevole e “post-Arduino”, è un’ulteriore scelta di libertà….
Per quanto riguarda il clock massimo, in verità, soprattutto per il miglior rapporto consumi/prestazioni, è preferibile fissare il clock a 8Mhz e comunque 16MHz sono un bel passo per la maggior parte delle applicazioni! Tieni presente che la serie Value Line in PDIP di cui fa parte il G22553 non ha comunque stadi idonei a supportare esigenze di calcolo importanti (vedi ad esempio un moltiplicatore Hardware o tantomeno un’unità Floating Point). All’interno della gamma MSP430, tuttavia, mantenendo lo stesso Core, ci sono MCU interessanti anche con periferiche specifiche, come nel caso dell’FR5969 citato nell’articolo, che ad esempio include un coprocessore crittografico AES a 256 bit.
Complimenti per l’articolo, ben scritto e soprattutto per il chiaro orientamento didattico (sono sensibile a questo aspetto!). Forse chi cerca soluzioni “semplici” e “pronte all’uso” potrà essere spaventato, ma credo che la strada che indichi sia molto valida per imparare veramente a programmare ed utilizzare i microcontrollori. In particolare mi sembra degno di nota l’insieme di tutte le tecnologie disponibili che citi (e non ti limiti a fornirne sola!), come base per ulteriori approfondimenti (eclipse su tutti).
Ci sono, però alcune cose, che vorrei chiedere. La prima è solo curiosità: non ho capito se l’hardware è open source come arduino o ti devi limitare a comprare le loro schede. L’altra riguarda le FRAM: ne parli come di tecnologia consolidata, ma sarebbe stato utile almeno un link a qualche risorsa per approfondire. Magari potrebbe essere l’idea per un articolo 😉
Di F-RAM abbiamo parlato qui:
http://it.emcelettronica.com/ramtron-f-ram-lalternativa-flash-ed-eeprom
e qui
http://it.emcelettronica.com/fram-e-100-volte-piu-veloce-della-flash
Riguardo a TI, tutte le demoboard hanno lo schema open, ma sono sicuro ti risponderà esaustivamente Stefano 🙂
Grazie. Evidentemente mi era sfuggito qualche articolo! 🙂 Ammetto che avrei potuto fare una ricerca, ma un link avrebbe aiutato, però 😉
Gianluca,
grazie per il commento. La FRAM è in effetti una tecnologia consolidata, nel senso che non è confinata in laboratorio a un ambito sperimentale o di ricerca, ma è stata anche resa disponibile sul mercato. In ambito applicativo, invece, con particolare riguardo ai microcontrollori, essa è ancora agli inizi e la scheda (e il relativo MCU) è una delle primissime occasioni (se non la prima in assoluto) per iniziare a sperimentare con questa nuova tecnologia di memoria. Essa permette sostanzialmente (per molte applicazioni tipiche dei microcontrollori di questa fascia) di eliminare la distinzione tra memoria veloce ma volatile (SRAM) e memoria di massa molto più lenta (specie in scrittura) ma persistente (EPROM/FLASH). In questo modo potrai, più che altro per ragioni di compatibilità del codice con altri Device che utilizzano della memoria nella configurazione tradizionale, partizionare logicamente la FRAM (che a livello fisico rimane unitaria) secondo lo schema che ti è più utile.
Quanto alla licenza Hardware dei Launchpad Texas Instruments, ti ha risposto correttamente Emanuele. Esse sono completamente aperte e riproducibili pari pari, anche secondo gli schemi che TI fornisce (a loro interessa vendere i microcontrollori, possibilmente in grandi quantità ;-), ma esistono anche Devboard su base MSP430 di terze parti (ad esempio Olimex:)
https://www.olimex.com/Products/MSP430/Starter/
Naturalmente dubito che tu possa risparmiare costruendoti un pezzo singolo identico a un Launchpad da solo, e comunque finito lo sviluppo del tuo progetto, magari ti verrà piuttosto voglia di farti la tua basetta Custom con il minimo necessario per la gestione del MCU e i componenti extra sopra…
Grazie di questo bell’articolo.
Condivido molto le considerazioni in merito ad Arduino. infatti io mi sono fatto le ossa con i micro della Microchip in linguaggio assembler e sinceramente anche oggi dovendo affrontare un nuovo progetto la prima scelta cade sempre sui PIC. Arduino è limitante perchè ha un certo tipo di conoscenze e vuole sfruttare al massimo l’HW a disposizione. Ha avuto e ha però l’indiscutibile pregio di aver fatto avvicinare la modo dell’elettronica e delle programmazioni moltissime persone. Non conosco le MCU della Texas ma dopo aver letto l’articolo mi è quasi venuta voglia di acquistare un launchpad
tra l’altro uso eclipse per sviluppo di piccole app per android e lavoro in linux, quindi ..
ciao
Grazie a te per il commento. Tra l’altro, se ami l’Assembler, troverai moltissime applicazioni e librerie scritte in questo linguaggio, che ovviamente brilla per stringatezza ma anche per l’eleganza di alcune implementazioni iper-ottimizzate. Il core, essendo RISC ha solo 27 istruzioni native, più altre 24 emulate, con un indirizzamento comodo e ben 12 registri generali, tutti a 16 bit. Se, tuttavia, l’aspetto che ti piace di più è quello di smanettare con la memoria, spremendo come un limone l’MCU anche per tua soddisfazione personale, qui trovi pane per i tuoi denti. Sia perché puoi mischiare liberamente C e Assembler (oltretutto guardandoti il codice compilato), sia per la presenza di un Debugger per navigare nei meandri della memoria e delle periferiche.
Quello che descrivi mi sembra in linea con quanto offre l’MPLAB di Microchip, oggi in una versione X realizzata con Java, quindi cross-platform (OK in Linux).
Sapresti dirmi quale è il vero valore aggiunto rispetto ai PIC per cui dovrei migrare a TI?
grazie
plot
Plotino,
grazie a te. Vorrei sgombrare subito il campo da un potenziale equivoco causato dal focus dell’articolo su Texas Instruments. Non era affatto mia intenzione affermare la superiorità di TI verso questa o quell’altra casa costruttrice o incentivare qualcuno a migrare, ma solo spendere due parole su di una famiglia di MCU che – almeno fra gli Hobbysti italiani – è molto meno nota degli ultrapopolari PIC (o anche Atmel). Se c’è qualcosa per cui tifo, semmai, è per un’evoluzione dell’appassionato, da una piattaforma ipersemplificata di Arduino/Wiring a un approccio basato su una Toolchain C, sull’apprendimento di un IDE serio, sul Debugging Hardware e sullo studio della documentazione. Il che, tra l’altro, rende l’apprendimento universale e valido per qualunque marca o modello di MCU. Nel caso di Microchip poi, che per molti come me è stata per anni sinonimo di microcontrollori, c’è solo da togliersi il cappello. D’altra parte quelli come te, che probabilmente magari avranno iniziato sbattendo la testa con l’Assembler, hanno tutti gli strumenti per valutare l’offerta Device/Software/documentazione di ogni casa e magari sperimentarne più d’una direttamente. A tutti gli altri, al di là dell’esempio di TI, l’articolo ambisce, se non altro, a fornire alcuni spunti specifici e una chiave di lettura da cui partire per impostare tali confronti.
OK.
nella miriade di scelte che il mercato oggi offre vedo però il rischio di passare più tempo a scrivere e testare “hello world” nei vari ambienti di sviluppo che ad iniziare a programmare per qualche vero progetto. Cioè alla fine uno si deve fermare e cominciare a lavorare con gli strumenti che ha scelto altrimenti rimane per sempre nel limbo della didattica.
saluti
plot
Ciao Stefano,
se non erro, questo e il 1° articolo che pubblichi su EOS, vero? Complimenti! Soprattutto per il tuo italiano: assolutamente impeccabile.
Ciao Marco,
non sbagli. Ti ringrazio, ho solamente cercato di mantenere un rigore adeguato nel linguaggio, soprattutto per una questione di rispetto dei lettori, fra i quali ci sono dei grandi cultori di un’altra forma – quella matematica – come te.
Ciao Stefano,
mi aggiungo ai ringraziamenti e ai complimenti per il tuo articolo.
Mi piace molto il taglio “didattico” che hai scelto senza debordare in un discorso troppo teorico e accademico. Apprezzo anche i numerosi riferimenti alle risorse visto che la vastita’ della documentazione TI puo’ facilmente disorientare.
Mi trovo nella condizione di iniziare un percorso molto simile a quello che tu hai descritto.
In realta’ conosco il C (e altri linguaggi anche ad oggetti) abbastanza bene in quanto programmo per PC e embedded (x86 e ARM) da diversi anni.
Siccome per lavoro spesso mi trovo ad interagire con sistemi a microcontrollore (progettati e programmati da altri colleghi o aziende) e siccome ho da sempre la passione per l’elettronica digitale, il mondo dei makers ecc., ho deciso di conoscere meglio anche questa parte del mondo.
So bene che le competenze, l’esperienza e le capacita’ per progettare e sviluppare soluzioni professionali, soprattutto in contensti “delicati” (biomedicale, automazione, ecc) non si improvvisano, ma capire meglio come funzionano le cose penso mi possa aiutare a progettare e gestire meglio anche lo sviluppo di mia competenza (solitamente di piu’ alto livello, HMI, integrazione di sistemi…).
Fatta questa premessa, la mia idea era di partire con lo studio del C per i micro della ATMEL, partendo dai classici ATMega presenti nei vari Arduino (di cui ho qualche esemplare).
Ho gia’ una Atmel Dragon per le operazioni di programmazione e debug e l’idea era di arrivare a scalare poi verso soluzioni anche piu’ complesse attraverso le famiglie UC3 (usate ad esempio da un collega in uno degli ultimi lavori).
Mi sono gia’ dotato di un paio di testi che spero mi possano guidare in maniera efficace attraverso questo percorso.
Ora, la lettura del tuo articolo ha un po’ fatto vacillare i miei piani 🙂
Ammetto di avere una scheda Launchpad da diversi mesi chiusa in un cassetto. Acquistata a seguito di una mega offerta appena uscita a pochi dollari, provata con Energia (che ai tempi era ancora solo in beta) e poi mai piu’ usata in favore dei vari arduino UNO e Nano di cui ho trovato (almeno allora) migliori esempi di utilizzo e tutorial.
Adesso la tua esperienza me la fa riconsiderare. (tra l’altro ho anche una BeagleBone Black e quindi ho potuto gia’ vedere che il mondo TI, in termini di documentazione e software e’ piuttosto ben fornito)
Devo decidere quali dei due ambienti, dal punto di vista didattico, sia migliore. Poi (immagino) il passaggio da una all’altra potrebbe essere meno indolore, una volta apprese le basi. Sbaglio?
In entrambi i casi userei Eclipse, che gia’ uso e conosco. E anche perche’ voglio utlizzare sistemi Linux per la programmazione e il debug.
Nel caso di Atmel occorre usare un plugin “non ufficiale”, visto che l’unico IDE ormai fornito e supportato da Atmel esiste solo per windows 🙁
TI mi pare fornisca un migliore supporto a Linux, fornendo l’IDE Eclipse direttamente, ma ho visto che nella versione free ha delle limitazioni. Le ritieni importanti in questo percorso?
Entrambi i sistemi hanno ottime community alle spalle e una gamma di chip piuttosto ampia.
Finora dal punto di vista professionale, nelle commesse a cui ho lavorato, ho visto piu’ volte utillizati i micro Atmel o Microchip piuttosto che TI.
Avevo pensato quindi di restare in casa Atmel sia per la disponibilita’ di hw gia’ in mio possesso che per la possibilita’ di accedere eventualmente a consigli e conoscenze di colleghi.
Pero’ a questo punto mi piacerebbe avere anche un tuo parere (o di altri che conoscono entrambi i mondi). E’ una scelta che mi potrebbe vincolare oppure quello che si apprende su una piattaforma si trasferisce facilmente anche sull’altra?
Non mi preoccupo molto della parte C e manipolazione dei byte (che gia’ un po’ padroneggio dovendo sviluppare protocolli di comunicazione) piuttosto di tutta la parte di gestione dei registri per l’utilizzo dei vari servizi e periferiche.
Grazie per l’attenzione e complimenti ancora
Ivan,
vengo a te, ahimé prima del previsto (sono stato beffato dal treno soppresso per allagamenti e, pare, per furto di rame…sarà stato qualcuno della Comunità di EOS per fare qualche bobina?) Poiché ti dichiari programmatore Embedded su X86 e ARM (presumo serie A), colgo lo spunto per darti un anticipazione su quello che troverai nel magico mondo dei microcontrollori, dove alcune cose possono essere più semplici ma altre, invece, più complicate. Innanzitutto, per quanto riguarda la struttura Hardware, la differenza principale tra gli MCU e i Device che tu già utilizzi (la Beagleboard in tuo possesso è uno di questi), è che non sono dotati di MMU (Memory Management Unit, per chi non lo sapesse). Questo elemento, dal ruolo abbastanza auto-esplicativo, è quello che permette la gestione della memoria virtuale (segmentata e/o paginata), che ormai da tempo diamo per scontata nei nostri PC desktop e Server. L’utilizzo della memoria virtuale è il fattore abilitante principale (non l’unico), per la condivisione di risorse e di memoria fra processi (ovvero fra programmi in esecuzione), che possono essere eseguiti in contemporanea (realmente se vi siano tante CPU quanti sono i processi, oppure in modo anch’esso virtuale, nel caso ce ne sia una sola), grazie alla sapiente regia del programma supervisore, altrimenti noto come sistema operativo. Al di là delle classificazioni più o meno fumose e alle questioni di lana caprina, all’interno di un microcontrollore gira quasi sempre un solo processo – le subroutine sono quindi dei “sottoprocessi” temporanei ma esclusivi – al più interrotti per l’appunto dagli Interrupt, Software o Hardware. In pratica, tutto parte dalla main() e tutto vi ritorna, in un ciclo infinito. Su una macchina dotata di sistema operativo, possono invece girare in contemporanea più programmi (o processi pesanti) e più thread (o processi leggeri) all’interno di singoli processi pesanti. Per tagliare corto, se vorrai simulare questi comportamenti, negli MCU dovrai riscriverti (non completamente e non col copia/incolla, non ce ne sarebbe lo spazio e il S.O. con cui interfacciarti) le Fork() e le Wait()/Signal() coi relativi semafori, sapendo che, sul fronte della memoria, non avrai invece altra protezione che il tuo buon senso di programmatore.
Tanto per negare tutto quanto detto in questo paragrafo, ti segnalo l’esistenza di alcuni RTOS (S.O. in tempo reale) per MCU, che sono una specie di ibrido di quanto detto sopra, e che principalmente offrono delle API per semplificare la gestione di alcuni processi multipli e concorrenti, oltre che per implementare particolari interfacce (ad esempio grafiche, per LCD). Essi esulano, tuttavia, da questo contesto, perché dalla mia esperienza essi hanno senso e funzionano nella pratica solo quando si spremano microcontrollori potentissimi, velocissimi e iperdotati in termini di risorse, come gli ARM32 di fascia alta.
Per un programmatore cosiddetto “di sistema” come sei tu, quindi, si tratta di “disimparare” alcuni pezzi di C che normalmente negli MCU non si usano (per esempio della Libreria Standard e della STDIO, non userai le funzioni di formattazione della stampa se dovrai solo pilotare dei LED, o di I/O su file, se non c’è un File System) o si usano molto meno (vedi malloc()/free(), se hai solo necessità di memoria statica). Allo stesso tempo, però, dovrai dotarti di creatività ed ingegno, perché non avrai a disposizione tutta quella serie di librerie – che magari sono implementate ma sono troppo pesanti e inutilmente complete da utilizzare così come sono, per via delle risorse scarse – o di Tool che abbondano, ad esempio, in Linux e che puoi concatenare, magari con le Pipe. Invece, piuttosto, dovrai imparare a concentrarti sull’ottimizzazione del codice per il risparmio energetico estremo, che magari nei sistemi a cui sei abituato è comunque sotto il controllo praticamente esclusivo del S.O. e quindi accendere e poi spegnere tu la CPU a seconda della sua reale necessità. Sono solo alcuni esempi di un discorso più ampio, che però comprenderai facilmente da solo.
Tornando alla tua domanda, tanto per fare un quadro delle differenze nella programmazione, la mia risposta di fondo te l’ho già data nel precedente commento: a livello didattico non fa alcuna differenza. Si tratta solo di una questione di preferenza rispetto ai Tool che dovrai utilizzare. Poiché già mi hai detto che useresti Eclipse, sappi che CCS6 è una versione Customizzata dell’IDE, nel senso che è preconfigurata con i Plugin, gli Header e i generatori di Make per l’utilizzo con le schede di sviluppo Texas. Ai registri a cui alludi, ci si accede sempre usando delle costanti simboliche che sono delle abbreviazioni del dispositivo a cui si riferiscono (ad esempio TA0CTL1, si riferisce al primo (1) registro di controllo del primo (0) Timer di tipo B) e questo è comune a tutti gli MCU sotto C. Quindi scrivere: TA0CTL1 |= 0x0002 significa settare il secondo bit meno significativo del registro (che negli MSP430 sono tutti a 16 bit); e: TA0CTL1 &= ~(0x0002) significa azzerarlo. Questo vale per tutti gli MCU di tutte le case ed è proprio questo il bello di C: disinteressarsi dell’architettura sottostante, almeno per tutte le funzioni “coperte” dal linguaggio. Particolari istruzioni o comandi che sono invece “scoperti” (penso ad esempio alla rotazione dei bit oppure la definizione delle Interrupt Service Routine) potranno essere scritte avvalendosi di funzioni speciali fuori standard (le cosiddette “direttive Pragma”, che si riferiscono a istruzioni particolari dell’architettura, ma non solo a quelle, e che istruiscono il compilatore sul da farsi), che però sono implementate per l’appunto a livello di compilatori diversi, magari allo stesso modo per diverse architetture (capirai cosa voglio dire più avanti…).
Quest’ultima considerazione mi offre lo spunto per affrontare brevemente proprio l’argomento dei compilatori – ma forse sarebbe più corretto riferirsi alle intere Toolchain – per rispondere alla tua domanda sulle limitazioni del Code Composer Studio 6 di Texas, in versione “libera”. Prendendo ad esempio proprio il caso di Texas, va fatta una premessa proprio su CCS6, che forse non è chiara a molti e che sgombra subito il campo per l’utilizzo didattico. Finché al tuo computer è collegato un Launchpad MSP430 di TI, CCS6 ha tutte le funzionalità sbloccate ma con la sola limitazione nella dimensione del codice di 16Kb (comunque l’intera memoria del G22553). Volendo contestualizzare questa quantità, tuttavia, ti posso dire che è veramente tanto codice, almeno per scopi didattici, specie per l’architettura molto efficiente del 430. A questo proposito, se ti interessa quest’ultimo argomento, c’è un interessante White Paper competitivo qui, basato su un compilatore unico di terza parte, per rendere omogeneo il confronto:
http://www.ti.com/lit/an/slaa205c/slaa205c.pdf
Invece, qualora tu fossi uno sviluppatore professionista e volessi utilizzare dei programmatori diversi e magari multipli, per produrre una quantità di dispositivi (e non dei prototipi usando i Launchpad) e non volessi incorrere in alcuna limitazione, dovrai acquistare la licenza. Essa costa comunque ben poco rispetto al Target a cui si rivolge ed agli scopi per cui viene richiesta: meno di 500 USD. Ci sono, tuttavia, due alternative che puoi prendere in considerazione, agli estremi opposti di costo:
1) Puoi usare GCC e la sua Toolchain Open Source, naturalmente del tutto liberamente, senza limitazione alcuna e già nativamente dall’interno delle ultime versioni di CCS6. Tieni presente che l’architettura MSP430 è recentemente stata dichiarata supportata ufficialmente e verrà sviluppata direttamente da Red Hat, con il contributo attivo di TI. Texas sostiene che, pur producendo codice corretto (sennò non la supporterebbe di certo), essa sia meno ottimizzata specificamente per la piattaforma rispetto al suo compilatore proprietario. E’ stata anche rilasciata una prima Release dichiarata non-beta, sorgenti, binari e installatori, sia per Windows che per Linux, potrai trovarli qui:
http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/index_FDS.html
2) Puoi usare l’IDE di IAR dedicato IAR Embedded Workbench for TI MSP430, che anche Texas Instruments stessa definisce il miglior Tool di sviluppo e compilatore per la sua architettura. E’ gratis una versione Kickstart limitata a 8Kb (comunque parecchi e utile per un primo approccio), la licenza completa costa circa 3000 USD (in Euro, non saprei) e va richiesta una quotazione. Tanto? Poco? Probabilmente per un Hobbysta è buona la prima, per un professionista la seconda. Questo perché, e qui rispondo finalmente alla tua domanda, quando inizi a programmare i microcontrollori in C, dopo un po’ non sei più un programmatore Atmel, Microchip o Texas, come quando ci si limitava ai vari Assembler. Allora un professionista che con C ci si guadagna (bene) da vivere, spenderà di più per dei tool che, per il supporto tecnico, per le implementazioni coerenti delle pragma di cui ti dicevo sopra, per il supporto aggiornato di tutti i singoli dispositivi di una famiglia e le loro funzionalità, vuole un ambiente sempre uguale per non perdere tempo, per esempio per gli 8, per i 16, per i 32 bit di varie case, che spesso vengono utilizzati tutti come componenti di un intero sistema. Infatti, il vero ingegnere Embedded, non è un tifoso della Roma o della Lazio (avrai capito di dove sono…) che parteggia per una squadra o per l’altra, ma invece sceglie sempre il Device migliore (supportato dai Tool giusti, magari di terze parti, e da un’adeguata documentazione, che ormai offrono tutte le case) per il progetto o per i suoi vari pezzi. Non è, mi sembra, ancora il tuo caso. Infine, avendo il Debugger di Atmel il vantaggio di averlo integrato nei Launchpad rispetto, ad esempio a un Arduino, non sussiste più. Quindi, vai tranquillo con chi vuoi e imparati i concetti di fondo, tanto poi per riconvertirti nel passaggio da Hobbyista al tuo primo, vero progetto professionale, magari all’interno di un Team dove la piattaforma sarà specifica e non sarà scelta da te, ci metterai ben poco. Dovrai fare solo uno sforzo infinitesimale di lettura e comprensione dei Datasheet e del manuale dell’implementazione del compilatore (che nel caso di Texas ho Linkato nell’articolo, se vuoi farti un’idea), e adattarti all’interfaccia grafica di un eventuale IDE che non sia Eclipse.
Un’ulteriore, breve, considerazione, riguarda invece l’architettura del Core. E’ opinione comune (ma io non sono d’accordo) che l’utilità e il senso degli MCU sotto i 32 bit stia declinando velocemente, grazie alla concorrenza tra i licenziatari ARM. Io credo che, almeno per quanto riguarda i 16 bit, essi abbiano ancora molto senso, se non per ragioni di costo, almeno per i consumi, specie in particolari ambiti applicativi. Se ti dovessi dare un’indicazione, vai diretto sui 16 bit (quelli Atmel non li conosco, sono fermo ai loro 8 bit, se sono RISC come i Texas allora sono equivalenti), anche e soprattutto per comodità di programmazione: tutto è a 16 bit, non ci sono registri sdoppiati, l’indirizzamento è coerente e tanti altri vantaggi, che li rendono un ottimo trampolino di lancio per l’ARM32.
In conclusionissima, per quanto riguarda i tuoi dubbi sull’apprendimento del funzionamento delle periferiche (i servizi sono un concetto più da S.O. come trattato sopra), anche qui si tratta di una questione svincolata da quella della marca e della famiglia di microcontrollori. Esse, infatti, sono a contorno del Core (pur essendo spesso un fattore molto determinante nella scelta) e, tranne casi molto particolari, sono più o meno equivalenti per tutti (pur variando molto in prestazioni e complessità, anche all’interno delle varie famiglie). In questo ambito, specialmente per i comparatori e i convertitori A/D e D/A, ti saranno necessarie anche alcune nozioni di elettronica che normalmente sfuggono ai programmatori “puri”, seppure di sistema. Essi, infatti, pur avendo a che fare con l’Hardware – come nel caso dello sviluppo dei Driver – quasi sempre si interfacciano con i controllori dei Device, che già forniscono un’interfaccia digitale (e che spesso e volentieri sono microcontrollori loro stessi…) Le stesse considerazioni, comunque, valgono per l’aspetto dell’interfacciamento dell’MCU con sensori, attuatori e altri circuiti.
Spero di essere stato esauriente nella risposta, ma non noioso…ti auguro un ottimo lavoro…e fammi sapere cosa avrai scelto!
Ciao
Stefano
Ivan
scusami, rileggendo il commentone, mi sono reso conto di avere scritto qualcosa che può confondere le idee, in particolare quando faccio l’esempio della scrittura nel registro del Timer, della cui costante simbolica tra l’altro ho pure semplificato la trattazione, quel registro serve per quel Timer ma per il contatore 1…non farci caso…
Quella costante simbolica TA0CTL1 che rimpiazza l’indirizzo del registro, intesa come nome, la decide Texas Instruments nell’Header apposito già presente nei file del compilatore (che viene ovviamente riportato nel Datasheet) riferito al singolo Device (o in quello che si riferisce alla famiglia cui appartiene, dal quale, con un’opportuna macro “if” si farà riferimento alla specifica variante).
Un’altra casa, ad esempio, potrebbe decidere di chiamare l’indirizzo del registro per quella stessa periferica TM0ACTLX (che naturalmente rappresenterà il corretto indirizzo di quel registro di quel Timer nella mappa di memoria di quell’MCU).
Quello che volevo spiegare era che L’ISTRUZIONE delle operazioni di Set/Reset in C è uguale per tutti, non come in Assembler dove, a seconda dell’architettura, magari hai istruzioni di tipo diverso sia per nome, che per indirizzamento, che per lunghezza dell’operatore ecc. ecc. (ecco, ora mi sa che ti ho confuso le idee…mannaggia, ma non è importante….perché non ci fate editare i commenti?)
Wow Stefano, che dire? Una risposta che da sola vale quanto un nuovo articolo:)
Ti ringrazio tantissimo per il tempo che hai dedicato a rispondere puntualmente ai miei singoli dubbi.
Adesso ho le idee un po’ più chiare e soprattutto elementi che mi saranno senz’altro utili nella scelta.
La conclusione è quella che speravo, ovvero una discreta libertà che non mi dovrebbe legare troppo le mani, e già questo è un buono stimolo a partire.
Adesso raduno un po’ le idee e leggo qualcosa, poi non ho più scuse. Grazie ancora!
Ivan,
intanto ti ringrazio per il tuo commento così ricco di spunti, che mi offre l’opportunità di dare la mia opinione e quindi un consiglio concreto. Vorrei però farlo il più compiutamente possibile e oggi sono in viaggio con solo il cellulare, per cui ti pregherei di pazientare fino al mio ritorno (spero stasera). Citando un Chiambretti sanremiero, ti anticipo comunque fin d’ora che nel tuo caso, per l’approccio e lo spessore che dimostri, Texas o Atmel, comunque vada sarà un successo…
Ti ringrazio intanto per la risposta, sono molto curioso di conoscere le tue opinioni.
Riguardo al mio spessore….. bhe, e’ vero che ho messo su qualche chiletto di troppo, pero’ non mi sembra carino rimarcarlo 😀
Naturalmente la risposta definitiva a Ivan è pubblicata sopra a questa, ho fatto un po’ di confusione con l’impaginazione dei commenti…chissà se Sara o un altro Admin potrà spostarla…
In svariati anni di progettazione elettronica ho lavorato con microcontroller di Microchip, Atmel, Freescale, Renesas e TI, sono stato consulente/partner di un paio di queste e devo dire che si equivalgono tutte. Forse Hitachi e Mitsubishi erano legate un po’ troppo alla mentalità giapponese, ma con la fusione in Renesas, si sono allineate al mercato occidentale. Inoltre, con mezza giornata si è operativi su qualsiasi micro di ognuna delle case citate (ovviamente se si conoscono le basi di c e asm). Con l’MSP430 in particolare, la prima volta, dopo nemmeno 20 minuti stavo debuggando un reference design.
Una volta si era legati al sistema di sviluppo che costava parecchio, oggi è tutto diverso, bastano 20 euro per iniziare a debuggare.
Insomma non voglio dire scegli chi ti è più simpatico, ma siamo li…..
(intendo ovviante il FAE più disponibile e l’ambiente di sviluppo più user friendly, ma è soggettivo)
Grazie Emanuele anche per la tua risposta! Effettivamente le possibilità anche a basso costo per iniziare sono un bel aiuto e un notevole incentivo.
Ho quindi ormai capito che un sistema vale l’altro, dal punto di vista didattico. Adesso devo solo pensare a una sorta di progetto pilota come obiettivo finale, in modo da rendere più concreto lo studio e non rimanere troppo sul teorico. Comunque mi avete dato degli ottimi spunti! Grazie ancora
Grazie Stefano per il bellissimo articolo.
Si Texas Instruments è un mito, il mio primo programma in assoluto lo feci con la calcolatrice programmabile TI57.
Penso che proverò questa scheda.
Sergio
Sergio,
ti ringrazio per l’apprezzamento. Ti voglio Linkare un piccolo progettino Open che potrà farti piangere qualche lacrimuccia… In verità non è per il Launchpad MSP430, ma per il fratello maggiore Tiva (che costa appena 13 USD e che è basato su un Core ARM M4, ma è compatibile con Energia/Arduino e naturalmente lo si programma in C nello stesso identico IDE che useresti con l’MSP430. Potrebbe essere un’idea, anche per ammortizzare le spese di spedizione, o anche per esercitarsi nella comunicazione seriale, acquistarli tutti e due…)
http://e2e.ti.com/group/launchyourdesign/m/tivaarmmicrocontrollerprojects/665584
Questo è il Launchpad Tiva:
http://www.ti.com/tool/ek-tm4c123gxl
Inoltre, se sei pratico con l’inglese, è partito da una decina di giorni uno straordinario corso MOOC gratuito sull’Embedded Computing, offerto dalla University of Texas at Austin, tra le più prestigiose al mondo per l’elettronica digitale, che utilizza proprio quel Launchpad Tiva – insieme a una manciata di altri componenti facilmente reperibili – per i suoi laboratori (prima volta in assoluto che si svolgono delle esercitazioni pratica in un corso online…) Seguendolo, potrai imparare tutti i segreti della programmazione in C, sulla potentissima architettura ARM M, che rappresenta lo stato dell’arte per i microcontrollori a 32 bit.
http://www.edx.org/course/embedded-systems-shape-world-utaustinx-ut-6-02x#.VMAAb2O37tR
Dato che ho visto che mantieni un bel Blog sul mondo Arduino, ti segnalo anche quest’altro corso attualmente attivo della University of California Berkeley, incentrato sull’interfacciamento tra mondo analogico (sensori) e digitale (microcontrollori):
http://www.edx.org/course/electronic-interfaces-bridging-physical-uc-berkeleyx-ee40lx#.VMAA12O37tQ
Ci tengo a segnalarteli, perché a me sembra davvero incredibile che, frequentandoli quando si ha tempo, da casa e spendendo pochissimo – solo il costo (minimo) dei materiali didattici – si possa avere accesso a corsi di questo livello.
Un saluto
Stefano
Anche io il primo programma lo feci sulla TI57 di mio nonno. Mi ricordo aveva i caratteri rossi….
Avevo 13 anni ed a scuola si studiavano le vasche da bagno che si riempivano più o meno velocemente in base ai litri d’acqua al minuto che scorrevano…
Bei tempi quelli, poco dopo però iniziarono i primi scontri allo stadio. In curva Nord gli Irriducibili dell’RPN, nella Sud i Fedayn del SOA. Subito dopo gli anni di piombo, in cui nelle strade i proletari si sparavano in nome di Sir Clive o di Jack (Tramiel), gli altoborghesi giocavano con le armi di Nolan mentre i ricchi nelle loro ville si godevano i gingilli dei due Steve… Ce ne volle di tempo prima che arrivassero gli sceriffi Steve e Paul a mettere fine alla guerra di mafia… ma i ricchi continuarono (e perseverano tutt’ora) a godersi indisturbati i loro frutti…
🙂
Vi segnalo il link ad un corso online sulla piattaforma Coursera(eroga corsi gratuiti da parte delle più prestigiose università al mondo) .
Il corso in questione io volevo seguirlo e infatti mi ero preso il kit Texas consigliato da loro (potevo usare anche il mio Arduino), però poi per impegni lavorativi ho dovuto rinunciare, soprattutto perché non sarei riuscito a fare i test per poi ottenere un attestato che mi sarebbe servito per la borsa di ricerca che avevo.
Il corso è in francese perché fatto dal Politecnico di Losanna(Svizzera), però magari nei video ci saranno i sottotitoli in inglese.
https://www.coursera.org/course/microcontroleurs
Questa può essere un’ottima interfaccia per la scheda
http://embeddedcomputing.weebly.com/educational-boosterpack-mk-ii.html