Ho notato che molti utenti vorrebbero avvicinarsi al mondo dei microcontrollori. Ne intuiscono le potenzialità, capiscono che sono oggetti interessantissimi, qualcuno ha già studiato qualcosa a scuola ma non sanno come fare per iniziare da zero l' avventura che li porterà ad una discreta conoscenza degli stessi. In effetti il mercato ne offre parecchi, di diversi modelli e prezzi e bisogna anche dire che, nonostante si abbia la possibilità di accedere attraverso internet a tutte le informazioni, è difficile farsi un' idea su come iniziare, quale micro scegliere, come indirizzare i propri sforzi, cosa comprare. Nel forum arrivano continuamente richieste su come iniziare e su cosa fare per non fare errori. Ho pensato quindi di raccogliere i suggerimenti che io ed altri utenti di solito diamo in questo articolo.
Non essendo io un luminare dei microcontrollori qualsiasi aggiunta e commento utile ad integrare questo scritto è bene accetto. L' articolo contiene parecchie imprecisioni ma lo scopo è solo quello di far luce, di dare qualche informazione al neofita in modo che possa fare la sua scelta e procedere per la sua strada approfondendo gli argomenti da se.
Indice |
Un po' di storia
Conoscere la storia serve per capire il presente e questo non vale solo per le vicende umane ma anche per i micrcontrollori, quindi un accenno veloce alla loro storia ed alla loro evoluzione penso che sia molto utile per poter comprendere molte cose. Realizzare prodotti con i micro è stata una vera e propria rivoluzione. Prima dell' avvento dei microcontrollori single-chip si usavano i sistemi basati su microprocessori. Questi sistemi erano formati da diversi circuiti integrati: una CPU (Central Processing Unit, unità centrale di elaborazione), la memoria ROM (Read Only Memory, memoria di sola lettura non programmabile) o PROM (Programmable ROM, memoria di sola lettura programmabile) o EPROM (Erasable PROM, memoria di sola lettura programmabile e cancellabile) su cui risiedeva il programma, la memoria dati RAM (Random Access Memory, memoria di lettura e scrittura temporanea) e le periferiche d' ingresso/uscita, timers, interfacce per la comunicazione seriale etc. Per realizzare un sistema era quindi necessario unire insieme questi componenti in una scheda. Il microcontrollore single-chip fu una rivoluzione perché integrava tutti questi componenti in un solo circuito integrato riducendo le dimensioni. Ma avevano anche un altro vantaggio. Se i sistemi a microcprocessore erano comunque, secondo lo standard del tempo, sistemi potenti molte volte non era necessaria tutta quella potenza. Con i microprocessori si producevano i primi personal computers, apparecchiature di una certa potenza e complessità ma il mercato richiedeva anche altro. Un esempio potrà comprendere meglio il problema.
Per realizzare un orologio digitale c' erano due possibilità: utilizzare una manciata di integrati standard (contatori, decodifiche e compagnia cantante) oppure farsi realizzare un integrato custom, su misura. Nel primo caso il circuito diventava ingombrante e non sarebbe stato adatto per essere montato, ad esempio, nel cruscotto di un' automobile mentre realizzare un integrato custom voleva dire spendere veramente tanti soldi e farne produrre diversi milioni o decine di milioni di pezzi con costi esorbitanti. Non c' era una via di mezzo. D' altro canto utilizzare un sistema basato su un microprocessore non avrebbe avuto senso per un' applicazione come questa, sarebbe come usare un autotreno per consegnare la posta nelle buche delle lettere. Serviva una specie di computerino, un integrato semi-custom, che costasse poco e che si potesse produrre in quantità limitate (50-100 mila pezzi). In effetti i primi microcontrollori avevano una CPU piccola, poco potente e lenta, una memoria di programma minima, pochissima RAM ma sufficiente per realizzare l' orologio digitale dell' esempio.
Quindi si procedeva individuando il microcontrollore, si scriveva il programma, lo si provava, lo si consegnava al produttore, si aspettavano sei o otto mesi e poi si ricevevano i 50 mila integrati tutti programmati con il programma del cliente. Il programma era quello e non si poteva cambiare poichè la memoria di programma era una ROM il cui contenuto veniva programmato in fase di realizzazione del chip vero e proprio. Oggi tutto questo sembra incredibilmente rigido ma allora era un' opportunità non da poco. Per avere un' idea a spanne, rapportata ai prezzi di oggi, realizzare un custom voleva dire spendere parecchi milioni di euro per linea di produzione e farne produrre 10 milioni al prezzo di 1 euro l' uno, realizzare un microcontrollore voleva dire spendere in tutto 200 300 mila euro e produrre 50 mila pezzi al prezzo di 2 euro l' uno.
Inutile dire che non erano oggetti alla portata dell' hobbista o della piccola azienda!
Il passo successivo fu quello di realizzare microcontrollori con memoria EPROM programmabile dall' utente. Programmabile una sola volta ma pur sempre programmabile e questo rese accessibili i micro anche da parte di aziende di medie piccole dimensioni. Tuttavia i costi erano ancora relativamente alti perché per scrivere il programma e provarlo sul circuito era necessario acquistare l' emulatore, un apparecchio grande quanto uno scatolone, dal costo di diversi milioni di lire (migliaia di euro) che si collegava al PC e che aveva un "probe", un cavo flat con uno zoccolo che simulava il microcontrollore.
Bisognava anche comprare l' assembler per poter scrivere il programma (in assembly chiaramente) che costava un paio di milioni di lire (500-1000 euro di oggi e molte volte era fornito insieme all' emulatore), ma era abbordabile. Ricordo che il primo emulatore che ho comprato per realizzare un mio prodotto costava quanto un' utilitaria e non ho dormito per tre giorni prima di decidere di comprarlo.
Quindi riassumendo, ogni micro aveva il suo set d' istruzioni (tutti diversi uno dall' altro), si programmava in assembly e quindi era necessario imparare il set d' istruzioni di ogni micro e l' emulatore costava come il fuoco.
Poi arrivò il linguaggio C per i microcontrollori. Una goduria galattica, un solo linguaggio per scrivere programmi per tutti i micro, un miracolo! Epperò il compilatore C costava un sacco di soldi e quindi o si riusciva ad averlo gratis quando si comprava l' emulatore e a fronte di un sostanzioso ordine di diverse migliaia di pezzi oppure si andava con l' assembly che aveva un costo più abbordabile.
Il mondo va avanti e la tecnologia elettronica avanza a velocità vertiginosa. Oggi i microcontrollori non sono solo più macchine semplici e limitate ma vanno dal piccolo integratino che va bene per fare un lampeggiatore o il controllore per le luci di Natale al dispositivo multimediale in grado di pilotare schermi a colori, riprodurre musica e filmati, collegarsi ad internet, gestire tutte le funzionalità di un telefonino o di un televisore avanzato. Ce n'è per tutti i gusti ed applicazioni.
Lo sviluppo del firmware
Anche il modo di sviluppare il firmware ha subito evoluzioni. Per i microcontrollori piccoli ogni programma era un qualcosa di nuovo e non aveva senso sviluppare librerie, anche perché questi venivano spremuti come limoni ed era normale utilizzare trucchi di programmazione, quindi il processo di sviluppo era molto semplice. Si partiva da un unico sorgente in assebly che veniva compilato, scaricato nell' emulatore, provato in pratica, modificato e corretto secondo questo flusso.
Quando i micro diventarono più potenti lo sviluppo del firmware diventò uguale a quello utilizzato per sviluppare programmi per sistemi a microprocessore. Il programma poteva essere spezzettato in moduli, a volte scritti da persone diverse (che potevano poi diventare parte della libreria) che venivano assemblati dall' assembler e poi uniti fra di loro con il linker secondo questo flusso.
Con l' utilizzo dei compilatori si aggiungevano al programma sorgenti scritti in linguaggio evoluto che venivano poi uniti fra di loro con moduli scritti in assembly e librerie secondo questo flusso che è quello che si usa oggi.
Con la differenza che oggi non si usa più l' emulatore. Quello che ancora oggi si fa è mischiare assembly e C ma solo quando è indispensabile. Con l' assembly si sfrutta al massimo la macchina ma la programmazione è più pesante e quindi viene utilizzato solo se necessario. Ad esempio se ci sono problemi di velocità una routine scritta in assembly risulta più veloce e più compatta ma costa in termini di tempo e complessità.
Il linguaggio C
Molto sinteticamente il linguaggio C è stato un linguaggio di programmazione che ha avuto particolarmente successo al punto che oggi lo si può considerare il linguaggio universale per eccellenza. E' un linguaggio strutturato ad alto livello come lo era il Pascal (che ritengo sia il miglior linguaggio in assoluto) ma, a differenza del Pascal che era nato come linguaggio didattico, il C è diventato quello utilizzato a livello professionale praticamente per qualsiasi macchina, dal personal computer al piccolo microcontrollore. In C sono stati scritti i sistemi operativi Windows, Linux e Mac-OS per esempio. In buona sostanza oggi con il C si possono scrivere programmi per qualsiasi cosa, il che ha vantaggi enormi. Se è vero che ogni microprocessore o microcontrollore ha il suo set d' istruzioni assembly specifico, il C è universale. Non è più necessario imparare setto o otto set d' istruzioni a volte molto diversi fra di loro per lavorare con macchine diverse, basta conoscerne uno e si possono scrivere programmi per tutto.
Non ostante questo, programmi in assembly se ne scrivono sempre, sopratutto per ottenere le massime prestazioni dalla CPU o per realizzare programmi compatti e veloci, insomma quando si ha la necessità di "tirare il collo" al micro per ottenere il massimo ottenibile.
E' chiaro comunque che lo studio del C è comunque un sicuro investimento che permette di scrivere velocemente programmi e che, grazie agli ottimi compilatori che ci sono oggi, anche quelli gratuiti, risultano essere veloci e compatti.
Come si lavora oggi
Oggi le cose sono cambiate e fortunatamente si lavora in un altro modo rispetto al passato. Descriverò qui di seguito l' approccio che si adotta quando si ha la necessità di sviluppare un prodotto che utilizza un microcontrollore. Come dicevo prima le cose sono cambiate, oggi non si usa più l' emulatore e non si programma più il micro mettendolo nello zoccolo del programmatore ma, in linea di massima, tutti i micro hanno la possibilità di essere programmati in-circuit, ossia mentre sono montati nel circuito definitivo tramite un programmatore/debugger (ICE). Questo oggetto permette non solo di scaricare (programmare) la memoria del micro ma anche di farlo funzionare un' istruzione alla volta avendo così la possibilità d' individuare eventuali errori del programma. Generalmente ogni famiglia di micro ha il suo ICE (magari diversi modelli con più o meno funzioni e prestazioni più o meno elevate), alcuni invece possono utilizzare ICE universali come i micro basati su architettura ARM. In pratica abbiamo una configurazione hardware di questo tipo.
In pratica tutte le funzioni dell' emulatore vengono svolte dall' ICE in collaborazione con il micro stesso montato nel circuito finale. Lo sviluppo del firmware è rimasto uguale con la differenza che oggi molti compilatori C sono disponibili gratuitamente e forniti dai produttori di microcontrollori. Le aziende che producono i complilatori non sono però scomparse, ci sono ancora ed offrono prodotti d' eccellenza come la IAR. Chiaramente i loro compilatori costano parecchio e vengono utilizzati per applicazioni dove sono richieste le prestazioni massime.
Modelli, famiglie e costruttori
Oggi sul mercato si trovano veramente tante aziende che producono microcontrollori ed alcune di esse sono particolarmente apprezzate dagli hobbisti. I più grandi produttori come Renesas e colossi del genere non hanno bisogno di spingere la clientela ad usare i loro prodotti perché detengono le maggiori percentuali di mercato. Altri produttori invece hanno scelto una politica diversa. La Microchip, ad esempio, è stata la prima a fornire gratis il sistema di sviluppo per il PIC16. In effetti hanno preferito regalare gli strumenti software per lo sviluppo pur di vendere i loro prodotti. La Microchip oggi offre gratuitamente i compilatori C nella versione light, senza limitazioni di codice e che funzionano bene. La versione a pagamento produce un codice più compatto e voloce, più ottimizzato. La stessa cosa fa oggi Atmel che fornisce gratuitamente gli strumenti di sviluppo per i loro prodotti (mi pare) ad eccezione dei micro basati su architettura ARM. Altri forniscono compilatori in versione free ma limitati nella lunghezza del programma. Per alcune famiglie di micro esistono anche compilatori free come il gcc oppure l' SDCC che compila per i PIC ed i micro basati su architettura 8051.
8, 16 o 32 bit ?
I micro si distinguono principalmente dalla lunghezza in bit dei dati che possono trattare ma questo può anche avere poca importanza se si scrivono i programmi in C. Il C è quello che è e poco importa se poi il programma girerà su una macchina a 8 o 64 bit, dal punto di vista della programmazione non cambia niente. Quello che invece cambia è la complessità delle periferiche a bordo del micro e dai vari controllori, ad esempio, per le interrupt. Una macchina a 32 bit è di per se molto più potente di una macchina ad 8 bit ed i costruttori cercano di dotarle di periferiche versatili e potenti il che le porta inevitabilmente ad essere complesse e di comprensione né facile né veloce. Per iniziare è quindi necessario orientarsi verso micro semplici (ce ne sono di molto semplici a 16 bit e di molto complessi a 8 bit per esempio) quindi la lunghezza della parola non è sinonimo di semplicità anche se in genere gli 8 bit sono i più semplici da utilizzare. Un esempio può aiutare a capire meglio.
Un tipo di periferica utilizzata frequentemente è il timer. Nella sua versione più semplice è un contatore che si incrementa ogni impulso del clock di sistema e quando arriva ad un certo punto genera un segnale, accende un bit da qualche parte in modo che il programma si "accorga" che è passato un certo tempo, questo a grandi linee. Ma il timer, essendo un contatore potrebbe anche funzionare appunto come contatore contando impulsi che arrivano dall' esterno, avere uno o più registri di comparazione per potere generare autonomamente frequenze, segnali PWM, pilotare motori passo passo, generare diversi tipi di interrupt, avere registri di auto ricaricamento e via dicendo. Insomma può essere un qualcosa di molto semplice oppure di estremamente complesso. E questo non ha niente a che vedere con il fatto che il micro sia ad 8 o a 32 bit, dipende solo dalla complessità (che vuol dire anche versatilità) che il costruttore ha deciso di dargli. Quindi la cosa migliore da fare, sopratutto agli inizi, è individuare un micro semplice e fregarsene del resto. Per esempio il PIC24F04KA200 è un esempio di micro a 16 bit semplice mentre il PIC18F97J60 è un esempio di micro ad 8 bit complesso mentre l' STM32F407xx è un 32 bit molto potente e molto complesso.
Le soluzioni per l' hobbista
Innanzi tutto è necessario capire che cosa si vuole ottenere dalla sperimentazione con i micro. E' necessario interrogarsi per capire se l' obbiettivo finale è quello di ottenere risultati con il minimo sforzo o se si vuole imparare davvero qualcosa che potrà essere utile in futuro. E' la stessa differenza che passa, parlando di elettronica, fra un "saldacomponenti" ed uno sperimentatore. Il primo otterrà subito oggetti funzionanti, magari gratificanti ma non imparerà una cippa di niente, il secondo inizialmente di risultati ne vedrà pochi ma imparerà sicuramente qualcosa. Dopo un certo tempo i risultati arriveranno anche per il secondo tipo di approccio ma saranno sicuramente più gustosi mentre il primo continuerà a non capire neanche come e perché i circuiti da lui realizzati funzionano.
La stessa cosa capita con i microcontrollori. Se si vuole ottenere subito risultati allora ci sono soluzioni come arduino che offrono la pappa pronta, una ricca libreria, e risultati immediati. Inutile dire che si rimane comunque legati a quel tipo di microcontrollore ed a quelle librerie. Di sicuro si impara poco ma si fanno cose che funzionano. Un altro conto è incominciare a leggere i vari datasheet dei micro, informarsi sulle differenze, cercare di capire il loro funzionamento, iniziare con programmi semplici imparando di volta in volta cose nuove per arrivare poi un giorno ad usare anche le librerie ma con la consapevolezza di capire cosa fanno ed apprezzarle per quello che sono. Se una funzione di libreria che fa la conversione al volo di uno stream MP3 ha un senso poichè si tratta di un qualcosa di complesso ed è buona cosa avere già una libreria pronta da utilizzare, una funzione di libreria per programmare un pin come ingresso o uscita è una cosa inutile, pratica ma assolutamente inutile. Non giudico il tipo di approccio ma mi piace far notare le differenze. Un conto è sapere di essere in grado di scrivere una funzione particolarmente complicata ma preferire utilizzarne una di libreria già scritta e collaudata per risparmiare tempo, un altro è usare un qualcosa che non si conosce minimamente. Anche qui un esempio può aiutare a capire meglio il concetto.
Supponiamo di essere seduti all' interno di un aereo di linea ed avere un pulsante rosso con scritto sopra "decollo". Quando premo il pulsante "decollo" il comandante dell' aereo vede una spia accendersi e, insieme al copilota, esegue tutte le operazioni e fa decollare l' aereo. Se io non ho idea di cosa vuol dire pilotare un aereo potrei anche dire di essere capace a far decollare un aereo di linea ma se ho il brevetto di volo e so cosa vuol dire pilotare un aereo capisco quale lavoro fanno il comandante ed il copilota e lo apprezzo in pieno. Attenzione che questo non è un esempio esagerato perché è quello che capita quando si collega un micro come un ATmega328 o un un PIC18F2550 ad un modulo GSM. Questi micro, in confronto a quello che c'è dentro al modulo GSM, sono delle vere e proprie sputacchie. Un modulo GSM è un sistema costruito intorno ad un ARM9, un mostro 32bit che lavora a 300MHz con decine di MB di memoria ed un programma colossale per la gestione di tutto l' ambaradan. La differenza che passa fra il "pilotante" ed il modulo è la stessa che passa fra un triciclo ed un autotreno, un nano paralitico che comanda un gigante dotato di superpoteri. La stessa cosa succede con i moduli che fungono da WEB server collegati a micro piccolini. Sentire dire "l' ATmega328 si può collegare a internet ed alla rete GSM" è una bestemmia che, solo a sentirla, fa venire l' orticaria.
Cosa bisogna sapere per iniziare
Innanzi tutto conoscere la struttura dei microcontrollori in generale e di quello che si pensa di utilizzare in particolare. Questo vuol dire cercare in rete tutorial o libri che parlino dell' argomento e poi munirsi di pazienza ed incominciare a leggere i vari Family User Manual di alcuni microcontrollori. Non è un qualcosa che si fa in un paio di giorni, serve tempo, parecchio tempo. Diciamo che il tempo è proporzionale al livello di conoscenza che s' intende avere. Passare diverse settimane a studiare queste cose è da mettere in conto a meno di non optare per la "pappa pronta".
Poi è necessario conoscere la programmazione in assembly (almeno in linea generale) e magari il linguaggio C che consiglio caldamente. Il vantaggio del C è che si può studiare e provare sul PC scrivendo programmi semplici e provandone le varie funzionalità. In questa fase un buon libro per imparare la programmazione in C è un' ottima scelta. Anche in questo caso serve lo studio e, una volta preso un minimo di dimestichezza con il linguaggio si può passare a curiosare come sono scritti i programmi per i micro. Le application notes dei vari microcontrollori hanno sempre programmi semplici tipo i "blink" che sono programmi che fanno lampeggiare un LED, e che sono utili per farsi un' idea di come si programma. Per l' assembly il discorso è un po' più complicato. Se si vuole scrivere un programma in assembly bisogna conoscere molto bene l' architettura della MPU, i vari registri ed il set d' istruzioni. Ogni micro ha il suo set d' istruzioni e cambiare micro vuol dire ristudiare tutto dall' inizio.
ICE-debugger o bootloader?
Dell' ICE-debugger abbiamo già parlato prima, ora è necessario sapere cos' è un bootloader. Il bootloader è un programma resisdente in una zona della memoria del micro che permette di caricare un programma e di farlo eseguire senza bisogno di usare un programmatore. Il bootloader è nato da un' esigenza specifica: quella di poter ricaricare il programma nel micro senza usare l' apposito programmatore. E' un modo come un altro per avere la possibilità di aggiornare il programma sul posto, senza bisogno di apparecchiature specifiche ma semplicemente collegandosi con il micro attraverso una linea seriale o USB. Diciamolo chiaramente: non è un qualcosa nato per dare agli hobbisti la possibilità di programmare un micro senza spendere soldi per il programmatore ma per avere un sistema di auto-aggiornamento del firmware.
Tuttavia questa possibilità pare che sia molto apprezzata dagli hobbisti per vari motivi: l' idea di risparmiare una manciata di euro, il gusto sottile di poter programmare un micro, magari tribolando, ma senza dover scucire soldi o ... chi può dirlo? Alcune case come la Atmel forniscono alcuni micro come gli AT90 con un bootloader già programmato e il Pierin ne è un esempio. Si può anche poi cancellare ma quando si compra il componente questi ha già a bordo il bootloader. Anche i micro basati su architettura ARM hanno un bootloader in ROM, programmato dalla fabbrica e non cancellabile che può essere usato per questi scopi ma l' ICE-debugger ha molti vantaggi. Con l' ICE si possono ad esempio mettere all' interno del programma dei breakpoint, che in pratica bloccano il micro in quel punto in modo da potere continuare l' esecuzione del programma un' istruzione alla volta, leggere i registri interni, verificare lo stato delle periferiche, il tutto per la verifica del corretto funzionamento del firmware o l' individuazione di eventuali problemi. Personalmente preferisco usare gli ICE anche se raramente uso le funzioni di debugging. Però, se qualcosa va storto o mi trovo davanti ad un problema di cui non riesco ad individuare immediatamente la soluzione, il debugger è indubbiamente un valido aiuto. Secondo me sono soldi spesi bene, sopratutto se si comprano gli ICE forniti dalla casa costruttrice. Un ICE per gli ATmega come il Dragon costa una sessantina di euro, per i PIC (dai PIC10 ai PIC32) il PicKit-3 ne costa una cinquantina, niente in confronto a quello che costavano i vecchi emulatori.
Le schede di valutazione (evaluation boards)
Le schede di valutazione sono un sistema veloce per poter sperimentare un micro od una famiglia di micro. Bisogna però stare attenti perché, molte volte, la fregatura è dietro l' angolo. La cantonata più grande che ho preso è stato l' acquisto della MPLAB Starter Kit for PIC24F perché si tratta di una scheda puramente dimostrativa nel senso che serve solo ed unicamente a dimostrare al compratore che il micro in questione riesce a fare quello che la casa promette. In effetti la scheda ha un piccolo display in bianco e nero, una specie di tastiera a tocco, può gestire una pen drive ed è fornita un programma di demo il cui solo scopo è dimostrare di fare quello che promette di fare. Questo può essere sufficiente per un' azienda che decide di adottare tale micro ma assolutamente inutile per un hobbista perché:
- Non ci sono pin di I/O disponibile per un qualsiasi tipo di sperimentazione, fosse anche solo collegare un pulsante ed un LED
- Il programma di demo fa quello che dice di fare ma è mostruosamente complesso.
- E' difficile isolare le parti del programma di demo per poterle sperimentare singolarmente.
Una scheda di valutazione, sempre della Microchip, che invece ho trovato estremamente interessante e utile è la Low Pin Count USB Development Kit che ho acquistato quasi per scherzo. Questa scheda viene venduta insieme ad un adattatore indispensabile per sviluppare e fare il debugging con i PIC18F14K50, ha uno spazio millefori su cui montarci un circuito a cui collegare, a propria disrcezione, i vari pin del micro e viene fornita con un PCB di riserva o per cablare un prototipo. Insieme al PicKit3 ho sviluppato un adattatore USB-RS232 e la SCU.
Quindi ben vengano le schede di valutazione ma sceglietele con prudenza, analizzandole con calma, leggendo tutta la documentazione, ragionando sull' hardware e provando a capire se il software dimostrativo fornito possa essere in qualche modo utile per i propri scopi. Molte, troppe volte i programmi dimostrativi sono troppo legati all' hardware e si corre il rischio di comprare una qualcosa fine a se stesso.
Sul firmware dimostrativo vale la pena spendere qualche parola in più. Questi programmi (quasi sempre scritti in C) solitamente vengono scritti per essere utilizzati con schede diverse. Per renderli così flessibili i sorgenti vengono riempiti di direttive per la compilazione che li adattano a seconda dei casi per una scheda o un' altra. Il problema è che in questo modo il programma diventa estremamente complesso e difficilmente decifrabile da chi non l' ha scritto e quindi di poca o nessuna utilità. Quindi massima attenzione, che vuol dire non farsi prendere da facili entusiasmi ma leggere, analizzare, chiedere pareri a chi ha già utilizzato tali oggetti, scrivere nel forum ma dopo essersi informati al fine di dissipare eventuali dubbi specifici.
Conclusioni
Questo articoletto pieno di semplificazioni ed imprecisioni sicuramente attirerà addosso a me le ire e le rettifiche piccate dei vari professionisti che frequentano il forum. Vabbè, me ne farò una ragione se questo sarà servito al neofita per iniziare a capire qualcosina sui microcontrollori perché questo è lo scopo. In ogni caso invito chiunque sia in grado di integrarlo con utili informazioni ad inserire commenti e facendomi notare eventuali errori/semplificazioni esagerate e fuorvianti in modo da poterle correggere.
L' idea è quella di avere uno straccio di documento da far leggere al prossimo utente che esordirà con una frase del tipo "Premetto che non conosco i microcontrollori, vorrei fare qualcosa ma non ho proprio idea di come iniziare", quindi più info si aggiungono meglio è.
Buon lavoro e buone sperimentazioni a tutti. :)
MCS48 e COP400. Utili documenti per imparare
Girovagando in rete sono riuscito ad trovare un documento che è una pietra miliare dei microcontrollori: l' MCS48 Microcomputer User Manual.
L' MCS48 è un microcontrollore della Intel nato nel 1976. Inizialmente era disponibile in te modelli:
- 8048 La versione mascherata (programma in ROM scritto dalla stessa Intel) che si usava in produzione.
- 8035 La versione ROMLESS utilizzata dagli sviluppatori per la stesura del programma
- 8748 La versione EPROM finestrata per provare il prodotto finale prima di dare il via alla mascheratura.
Oggi i produttori di microcontrollori danno per scontato che lo sviluppatore ne conosca il funzionamento (almeno in via generale), la programmazione in assembly e la struttura generale. In passato non era così quindi i costruttori, all' interno dello User Manual, insegnavano anche la teroia del microcontrollore e la sua programmazione in modo dettagliato illustrando per filo e per segno il set di istruzioni. D' altro canto non esistevano i libri che ci sono oggi e quindi dare queste informazioni allo sviluppatore voleva dire promuovere il prodotto ed avere così dei nuovi clienti.
Questo documento contiene appunto anche questa specie di mini corso sui micro. Al tempo l' ho trovato estremamente istruttivo e mi è servito per capire bene il funzionamento dei micro in generale.
Invito quindi chi è interessato a leggerlo. Si possono ottenere due risultati: una maggior comprensione dei microcontrollori e la conoscenza di un pezzo di storia, di come eravamo e come lavoravamo noi sviluppatori.
MCS48 MICROCOMPUTER USER'S MANUAL
C' è un altro microcontrollore, un esempio di quello che potrebbe essere definito uno dei primi RISC, non tanto perché è stato progettato volutamente con un set d' istruzioni ridotto ma proprio perché il set d' istruzioni era povero e basta.
Si tratta della famiglia COP400 di cui ho trovato lo User's Guide. Interessanti sono i capitoli 3 (dove viene illustrato il set d' istruzioni) ed il capitolo 4 dove vengono illustrate le tecniche di programmazione.
COP400 Microcontoller Family - COPS Family User's Guide
Modifiche
16/12/2011 - Aggiunto paragrafo "Le schede di valutazione (evaluation borads)".
01/04/2012 - Aggiunto paragrafo "MCS48 e COP400. Utili documenti per imparare".