Per i principianti Arduino è un punto di partenza ideale che non richiede una profonda preparazione tecnica. Ma se siete ingegneri oppure maker che intendono utilizzare Arduino per prototipare il vostro innovativo prodotto hardware, dovete sapere con precisione come e perché funziona. Questo manuale tecnico descrive i dettagli di funzionamento interno ed esterno di questa piattaforma di prototipazione elettronica open source. Qui troverete informazioni sui microcontroller AVR, sulle librerie di Arduino, sulle shield, sui moduli e su altri componenti. I capitoli finali sono dedicati a progetti reali e avanzati che mettono in luce idee specifiche che potete utilizzare in altre applicazioni, fra i quali, oltre alle molte possibilità descritte su come personalizzare i componenti, troviamo un generatore di segnale programmabile e il design di un termostato intelligente.
J. M. Hughes è un ingegnere di sistemi integrati con più di 30 anni di esperienza in elettronica, sistemi aerospaziali e programmazione di applicazioni scientifiche. È stato il responsabile del surface imaging software sul Phoenix Mars Lander e ha fatto parte del team che ha sviluppato un innovativo interferometro laser eterodino per calibrare il controllo della posizione degli specchi sul telescopio spaziale James Webb.
Arduino per tecnici, ingegneri e maker
J. M. Hughes
Arduino per tecnici, ingegneri e maker Titolo originale: Arduino: A Technical Reference di J. M. Hughes
Authorized Italian translation of the English edition © John Hughes This translation is published and sold by permission of O’Reilly Media, Inc., the owner of all rights to publish and sell the same. Copyright per l’edizione italiana: © 2016 Tecniche Nuove S.p.A., via Eritrea 21, 20157 Milano Redazione: tel. 0239090258 e-mail:
[email protected] Vendite: tel. 0239090440, fax 0239090335 e-mail:
[email protected] http://www.tecnichenuove.com
ISBN: ISBN (PDF): ISBN (E-PUB):
978-88-481-3178-0 978-88-481-3179-7 978-88-481-3180-3
Tutti i diritti sono riservati. Nessuna parte del libro può essere riprodotta o diffusa con un mezzo qualsiasi, fotocopie, microfilm o altro, senza il permesso dell’editore All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted, by any means, electronic, mechanical photocopying, recording or otherwise without written permission from the publisher
Traduzione: Barbara Sansone Questo libro è disponibile e acquistabile in versione digitale su www.tecnichenuove.com.
Sommario
Prefazione Capitolo 1 - La famiglia di Arduino Una breve storia Tipi di dispositivi Arduino Gallerie di Arduino I dispositivi compatibili con Arduino I dispositivi compatibili con l’hardware I dispositivi compatibili con il software Le convenzioni per la nomenclatura di Arduino Che cosa posso fare con Arduino? Per maggiori informazioni
Capitolo 2 - Il microcontroller AVR La storia L’architettura interna La memoria interna Le funzioni periferiche I registri di controllo Le porte I/O digitali I timer/contatori da 8 bit I timer/contatori da 16 bit Il prescaler del timer/contatore Il comparatore analogico Il convertitore analogico-digitale Gli I/O seriali L’USART La SPI La TWI Gli interrupt Caratteristiche elettriche Per ulteriori informazioni
Capitolo 3 - I microcontroller AVR specifici per Arduino L’ATmega168/328 La memoria Le caratteristiche I package (contenitori) Le porte Le funzioni dei pin Gli input del comparatore analogico Gli input analogici Le interfacce seriali Gli I/O del timer/clock Gli interrupt esterni Le assegnazioni dei pin di Arduino
Le caratteristiche elettriche fondamentali L’ATmega1280/ATmega2560 La memoria Le caratteristiche I package Le porte Le funzioni dei pin Gli input del comparatore analogico Gli input analogici Le interfacce seriali Gli I/O del timer/clock Gli interrupt esterni Le assegnazioni dei pin di Arduino Le caratteristiche elettriche L’ATmega32U4 La memoria Le caratteristiche I package Le porte Le funzioni dei pin Gli input del comparatore analogico Gli input analogici Le interfacce seriali Gli I/O del timer/clock Gli interrupt esterni L’interfaccia USB 2.0 Le caratteristiche elettriche Le assegnazioni dei pin di Arduino I fuse bit Per ulteriori informazioni
Capitolo 4 - I dettagli tecnici di Arduino Caratteristiche e funzionalità di Arduino Le interfacce USB di Arduino Le dimensioni fisiche di Arduino I tipi di PCB Arduino di base I tipi di PCB Arduino con fattore di forma Mega I tipi di PCB Arduino con fattore di forma piccolo I tipi di PCB per scopi speciali Le configurazioni del pinout di Arduino Il layout dei pin dell’Arduino di base Il layout dei pin esteso di base Il layout dei pin sulla serie Mega I layout non standard Per ulteriori informazioni
Capitolo 5 - Programmare Arduino e i microcontroller AVR Il cross-compiling dei microcontroller I bootloader L’ambiente IDE di Arduino Installare l’IDE di Arduino Configurare l’IDE di Arduino Eseguire il cross-compiling con l’IDE di Arduino L’immagine eseguibile di Arduino Il processo di creazione del software di Arduino Le schede degli sketch L’architettura software di Arduino Il supporto del runtime: la funzione main() Uno sketch di esempio
Le costanti Le variabili globali Le librerie Utilizzare le librerie negli sketch Aggiungere una libreria nell’IDE di Arduino Creare librerie personalizzate Il codice sorgente di Arduino
Capitolo 6 - La vita senza l’IDE di Arduino Le alternative all’IDE PlatformIO Ino La toolchain di AVR Installare la toolchain make avr-gcc binutils avr-libc Costruire programmi C o C++ a partire da zero Compilare con avr-gcc o avr-g++ Diversi file sorgente e make Il linguaggio assembly di AVR Il modello di programmazione AVR Creare programmi in linguaggio assembly per AVR Le fonti del linguaggio assembly per AVR Caricare codice eseguibile sull’AVR La programmazione in-system Programmare con il bootloader Caricare senza il bootloader JTAG AVRDUDE Utilizzare un Arduino come un ISP L’azione del bootloader Sostituire il bootloader Riepilogo
Capitolo 7 - Le librerie di Arduino I componenti delle librerie Altre librerie
Capitolo 8 - Le shield Le caratteristiche elettriche delle shield Le caratteristiche fisiche delle shield Montare diverse shield una sopra l’altra Shield Arduino comuni Input/Output Shield di estensione I/O Shield d’espansione I/O Relè shield Shield che trasportano il segnale Memoria Comunicazione I/O seriale e MIDI Ethernet Bluetooth USB ZigBee CAN Prototipazione
Creare una shield di prototipazione personalizzata Controllo del movimento Controllo di motori DC e passo-passo Controllo di PWM e servomotori Display Shield per la strumentazione Shield adattatori Shield varie Shield di Arduino non comuni Fonti
Capitolo 9 - Moduli e componenti I/O I moduli I fattori di forma fisici Le interfacce Dove trovare i moduli Le descrizioni dei moduli I moduli TinkerKit I moduli Grove Descrizioni di sensori e moduli I sensori I sensori di temperatura, umidità e pressione I sensori di inclinazione I sensori audio I sensori di luminosità I sensori magnetici I sensori di vibrazioni e shock I sensori di movimento I sensori a contatto e di posizione I sensori di distanza Le comunicazioni I moduli wireless APC220 I moduli RF 315/433 MHz La ricetrasmittente ESP8266 Dispositivi e componenti di output Le fonti di luce I relè, i motori e i servo Gli output dei segnali analogici L’input dell’utente I tastierini I joystick I potenziometri e gli encoder rotativi L’output dell’utente I display di testo I display grafici Funzioni di supporto I clock I timer Le connessioni Lavorare con ponticelli nudi I sistemi di connessione dei moduli Costruire connettori personalizzati Scegliere un metodo di connessione Fonti Riepilogo
Capitolo 10 - Creare componenti personalizzati Per cominciare Le shield personalizzate
Considerazioni fisiche Montare le shield una sopra l’altra Considerazioni elettriche La shield personalizzata GreenShield Obiettivi La definizione e la pianificazione Il design Il collaudo finale Il funzionamento Prossimi passaggi Design personalizzati compatibili con Arduino Programmare un design personalizzato Lo Switchinator La definizione e la pianificazione Il design Il prototipo Il software La produzione Il collaudo Prossimi passaggi Fonti
Capitolo 11 - Progetto: un generatore di segnale programmabile Gli obiettivi del progetto La definizione e la pianificazione Il design Le funzionalità La custodia Lo schema Il prototipo Gli input dei controlli e le modalità La visualizzazione dell’output Il modulo DDS Il software L’organizzazione del codice sorgente La descrizione del software La libreria DDS I test L’assemblaggio finale Le resistenze pull-up La protezione degli input I componenti dello chassis L’alimentazione I test finali e la chiusura Ridurre il costo Il costo nel dettaglio Fonti
Capitolo 12 - Progetto: un termostato intelligente Gli antefatti Panoramica dei sistemi HVAC Concetti fondamentali del controllo della temperatura Il controllo intelligente della temperatura Gli obiettivi del progetto La definizione e la pianificazione Il design Le funzionalità La custodia Lo schema
Il software Gli input/output dell’utente L’output dei controlli Il prototipo Il sensore DHT22 L’encoder rotativo Il modulo real-time clock La shield LCD Il software L’organizzazione del codice sorgente La descrizione del software I test La versione finale L’assemblaggio I test e il funzionamento Il costo nel dettaglio Prossimi passaggi Fonti
Capitolo 13 - Il modellino di lanciarazzi: lo studio di un design Panoramica Il ciclo del design Gli obiettivi Selezionare e definire i requisiti funzionali Creare il design preliminare La fattibilità del design L’elenco preliminare dei componenti Il prototipo Il design finale Gli aspetti elettrici Gli aspetti fisici Il software I test e il funzionamento Analisi dei costi
Prefazione
Quando fu introdotto nel 2005, Arduino diventò immediatamente uno dei progetti di hardware open source più di successo del mondo (alcuni direbbero quello più di successo). Schede dal design aperto rilasciate dal team di Arduino cominciarono a essere prodotte in vari paesi del mondo, come Italia, Brasile, Cina, Paesi Bassi, India e Stati Uniti. È possibile acquistare una scheda compatibile con Arduino pienamente funzionante per circa 15 € e l’ambiente di sviluppo di Arduino è disponibile per essere scaricato immediatamente e del tutto gratuitamente. Arduino, che all’inizio si basava sulla famiglia di microcontroller AVR da 8 bit (l’AVR di per sé è un dispositivo interessante con una storia altrettanto interessante), si è poi spostato nel regno dei 32 bit, con l’aggiunta del modello Due con processore ARM, del Yún con un modulo sulla scheda che utilizza la versione OpenWrt di Linux e con l’imminente modello Zero. Le schede Arduino possono essere utilizzate per molti scopi diversi, dall’interattività alla robotica, da sensori ambientali ai piccoli satelliti “CubeSat” che piccoli gruppi possono costruire e lanciare con una spesa molto ridotta rispetto a quella che comporterebbe un satellite di dimensione normale. Io ho comprato il mio primo Arduino (un Duemilanove) molti anni fa, più che altro per curiosità. Lavoro su sistemi di sviluppo con microprocessori e microcontroller dall’inizio degli anni ’80: ho cominciato con il 6502, il 6800 e l’8051 e poi sono passato all’8086, allo Z80, l’80186 e alla famiglia dei 68000. In passato di solito programmavo questi dispositivi in linguaggio assembly o PL/M, dal momento che allora queste erano davvero le uniche scelte razionali per i sistemi integrati. Più tardi è diventato possibile utilizzare C o Ada, dal momento che le capacità dei microprocessori erano migliorate e che gli strumenti software erano maturati. In ogni caso, tuttavia, mi aspettavo sempre di trovare a mia disposizione diversi materiali di riferimento: schede tecniche, manuali pesanti o tascabili e documentazione di vario tipo che accompagnassero la scheda e i suoi accessori. Il tutto generalmente arrivava in una grande e pesante scatola. Quando è arrivato il mio primo Arduino, ho aperto la minuscola scatolina e vi ho trovato dentro soltanto una scheda elettronica, un alimentatore, alcuni LED e qualche resistenza, alcuni ponticelli e una breadboard che non richiede saldature. Nessun manuale, nessuno libro e nessuna scheda tecnica. Nemmeno un CD che contenesse documenti e software. Nient’altro che qualche foglio di carta con un manifesto di quello che conteneva la scatola e l’URL della pagina web dove si potevano trovare alcuni materiali su “da dove cominciare” e i link del software necessario. Sono rimasto davvero sorpreso.
Ero anche ignorante. Quando ho comprato la scheda Arduino non conoscevo del tutto la sua storia, né ero cosciente di quale fosse il pubblico al quale era diretta. Si dà il caso che all’inizio sia stata pensata per persone con una base tecnica minima o nulla, che semplicemente volessero fare esperimenti (in senso ludico) con qualcosa di divertente e creare cose funzionanti. In altre parole, ad artisti e tinkerer, non a ingegneri con un’inclinazione per i dettagli tecnici e la passione per i progetti, le specifiche e, ovviamente, i manuali. Una volta che ho capito questo, tutto ha cominciato ad avere più senso. Leggendo il libro di Massimo Banzi Getting Started with Arduino (O’Reilly) ho afferrato meglio la filosofia di Arduino e ho trovato un ottimo punto di partenza per la mia sete di ulteriori dettagli. Inoltre, a differenza dei produttori di semiconduttori con i loro kit di sviluppo, la gente del team di Arduino non aveva intenzione di fare soldi vendendo i suoi chip: lavorava per ispirare la creatività. Il microcontroller AVR è stato scelto perché poteva essere applicato rapidamente a un progetto creativo. L’AVR è dotato di abbastanza potere di calcolo e di sufficiente memoria integrata da riuscire a eseguire lavori complessi e interessanti, a differenza delle generazioni precedenti di microcontroller che di solito richiedevano costosi strumenti di sviluppo e offrivano soltanto scarse quantità di memoria interna sul chip. Lasciando da parte la semplicità e il basso costo, il vero segreto del successo di Arduino è il bootloader del firmware del chip AVR, associato a un ambiente di sviluppo integrato (IDE, integrated development environment) semplice e facile da utilizzare e alle librerie di codice che lo completano, tutte fornite gratuitamente sotto licenza open source e Creative Commons. La filosofia di Arduino impone di rendere più facile possibile l’utilizzo della scheda. Eliminando tutta la difficoltà dei dettagli tecnici e semplificando il processo di sviluppo, Arduino invita l’utente a sperimentare, provare nuove cose e, sì, giocare. Per la prima volta dopo molto tempo mi sono ritrovato davvero a divertirmi moltissimo, semplicemente collegando cose in combinazioni diverse per vedere che cosa potevo fare. Mi sarebbe piaciuto aver potuto disporre di Arduino quando insegnavo le basi del design dei sistemi integrati: mi avrebbe aiutato a ridurre molta della frustrazione che sentivano i miei allievi quando cercavano di orientarsi tra i listing, le mappe di memoria e i diagrammi di flusso del linguaggio assembly. Quando ho cominciato a lavorare con il mio primo Arduino, ho scoperto molte risorse utili e interessanti sui componenti aggiuntivi per la famiglia di Arduino, alcuni dei quali davvero incredibili in termini di prezzo e capacità1. Infatti, sono diventato una sorta di collezionista di Arduino, di quelli che comprano shield e moduli economici e costruiscono una considerevole raccolta di cose. Ma, purtroppo, devo dire che molte volte ho aperto una confezione con dentro un nuovo aggeggio interessante, soltanto per scoprire che non conteneva documentazione di nessun tipo. Nemmeno un semplice diagramma dei collegamenti. Essendo io un ingegnere, trovo particolarmente frustrante comprare qualcosa di interessante, per poi scoprire che non è accompagnato dalla sua documentazione. Quindi devo mettermi a cercare di scoprire se questa documentazione esiste e se è
disponibile in una forma che mi permetta di leggerla (per esempio, non in cinese). A volte questa ricerca non dà frutti e per eseguire l’ingegneria inversa della scheda elettronica e scoprire come collegarla mi trovo costretto a consultare le schede tecniche dei componenti. Altre volte le informazioni che cerco esistono, ma sono sparse in diversi siti web suddivise in vari pezzi. Questa situazione sta lentamente migliorando, ma può rivelarsi ancora difficile. Dopo aver collezionato per anni note, link di pagine web e schede tecniche, alla fine ho deciso di organizzare il tutto e riunirlo in un unico posto. E quindi, cosa c’è in questo libro che non si può trovare altrove su Internet? Non molto, a essere onesti, ma la mia speranza è che aiuti a ridurre molta della frustrazione che potenzialmente si accumula e del tempo che si perde e ovviamente contiene anche varie cose che ho scoperto da solo. I dati tecnici ufficiali provengono da produttori come Atmel, il team di Arduino e numerose altre fonti, alcune delle quali molto note e altre meno. Alcuni rivenditori d’oltreoceano dispongono soltanto di siti web molto semplici, mentre altri sono dotati di siti web molto belli con link ad altri siti dove si può trovare della documentazione. Questo libro contiene tutti i dati essenziali che sono riuscito a trovare o a ricostruire, tutti in un unico posto comodo da consultare, con tutti i collegamenti che sono riuscito a gestire. Il mio obiettivo è evitare ad altri la frustrazione che ho provato cercando di scoprire un semplice dettaglio tecnico sull’interfaccia USB, oppure di capire perché una shield non funzionava correttamente, oppure ancora perché quel sensore che avevo comprato da qualcuno su eBay sembrava non funzionare affatto. Il risultato delle mie frustrazioni è questo libro, quello che avrei voluto avere per lavorare con le schede e le shield di Arduino. Mi sarebbe davvero piaciuto avere qualcosa di fisico da tenere vicino e a portata di mano sul mio tavolo di lavoro. Non sempre è comodo dover consultare una pagina web per cercare qualcosa e, per rendere le cose ancora più interessanti, a volte l’accesso a Internet non è disponibile (come quando stai cercando di eseguire il debug di un dispositivo di logging remoto sulla cima di una montagna accompagnato soltanto a un piccolo computer portatile e nessun servizio wireless nel raggio di 60 chilometri). Mi sarebbe piaciuto disporre di qualcosa da poter utilizzare rapidamente per cercare la risposta a una domanda mentre lavoravo con Arduino e i suoi componenti aggiuntivi associati, a prescindere da dove mi trovassi. Per quello che ne so, una cosa del genere non esisteva prima di adesso. Spero che troverete questo libro utile quanto lo ho ritenuto io mentre riunivo i miei appunti per scriverlo.
A chi è diretto Questo libro è diretto a quelle persone che hanno bisogno o vogliono scoprire i dettagli tecnici. Magari siete arrivati fino a dove potevate con il materiale introduttivo e libri del tipo “99 progetti incredibili” e adesso volete scoprire come fare qualcosa di nuovo e unico. Oppure potete essere ingegneri o ricercatori che vorrebbero includere Arduino nel loro laboratorio sperimentale. Potete anche essere qualcuno che desidera installare
un Arduino in un aereo RC, utilizzarlo in una stazione meteorologica DIY 2, oppure magari per fare qualcosa di ancora più ambizioso (per esempio un CubeSat?). Idealmente, dovreste avere una preparazione di base di C o C++, qualche idea di come si muovono gli elettroni in un circuito e un po’ di esperienza nella costruzione di dispositivi elettronici. Se me lo permettete, vi suggerirei di procurarvi una copia del mio libro Practical Electronics: Components and Techniques (edito anche questo da O’Reilly) e di tenerlo a portata di mano, insieme ad altri testi di riferimento sulla programmazione e l’elettronica (troverete altri consigli nell’Appendice D).
Che cos’è questo libro Questo libro è un manuale da leggere o da consultare. Ho cercato di organizzarlo in modo da permettervi di trovare rapidamente e facilmente quello che cercate. Ogni volta che è stato possibile vi ho incluso le fonti delle mie informazioni, mentre le intuizioni che sono emerse dalla mie ricerche personali sono contrassegnate come tali.
Che cosa non è questo libro Questo libro non è un tutorial. Questo non è il suo scopo principale. Qui non ho incluso i concetti fondamentali dell’elettronica, né vi troverete una descrizione del dialetto del linguaggio C++ che si utilizza per creare i cosiddetti “sketch” per programmare un Arduino. Esistono già degli eccellenti tutorial che trattano la teoria generale dell’elettronica e della programmazione e li segnalerò al lettore come punti di partenza per prendere confidenza con questi argomenti. Questo libro non è neppure una guida ufficiale di Arduino e dei prodotti del team di Arduino. Si basa su informazioni raccolte da diverse fonti, alcune meno note di altre, insieme ai miei appunti e commenti personali basati sulle mie esperienze con Arduino. Pertanto, sono l’unico responsabile di eventuali errori e omissioni.
La terminologia Le distinzioni tra processori, microprocessori e microcontroller è sorta a un certo punto all’inizio degli anni ’80, quando i produttori cercavano di distinguere i loro prodotti basandosi sulla dimensione e la quantità di circuiti esterni necessari perché i dispositivi facessero qualcosa di utile. Per poter risultare utili, i processori completi più comuni e quelli più piccoli come quelli che generalmente si montano sui computer portatili richiedono alcuni componenti esterni (alcuni ne richiedono parecchi). Un microcontroller, invece, ha già integrato tutto il necessario per fare il suo lavoro. Inoltre, un
microprocessore di solito supporta una memoria esterna, mentre microcontroller può offrire soltanto un supporto limitato (o non offrirlo del tutto) a una memoria ulteriore rispetto a quella che si trova già sul chip. In questo libro, utilizzerò i termini “microcontroller” e “processore” in maniera intercambiabile. Anche se “microcontroller” può essere considerato un termine tecnicamente più corretto, nella mia mente è comunque un processore di dati, anche se una versione più ridotta rispetto alle enormi macchine con le quali lavoravo in un passato ormai lontano. Tutti essenzialmente fanno la stessa cosa, soltanto a scale e velocità di elaborazioni diverse.
Che cosa c’è in questo libro Il Capitolo 1 presenta una breve storia di Arduino nelle sue varie forme. Presenta anche i microcontroller AVR utilizzati sulle schede Arduino e mostra le differenze tra prodotti basati su Arduino e compatibili con il suo software e hardware. Il microcontroller Atmel AVR è il protagonista del Capitolo 2. Questo vuole essere una panoramica di quello che in realtà è un dispositivo molto sofisticato e quindi questo capitolo offre uno sguardo rapido sulle caratteristiche principali, come la logica del timer, il comparatore analogico, l’input analogico, l’interfaccia SPI e altri sottosistemi primari del chip. Il Capitolo 3 offre uno sguardo più da vicino sui microcontroller AVR utilizzati sulle schede Arduino, cioè i dispositivi ATmega168/328, ATmega1280/2560 e ATmega32U4. Riprende la panoramica presentata nel Capitolo 2 e propone alcuni ulteriori dettagli di basso livello come l’architettura interna, le caratteristiche elettriche e i pinout del chip. Il Capitolo 4 parla delle caratteristiche fisiche e delle funzioni dell’interfaccia di varie schede Arduino. Queste comprendono i tipi di interfaccia USB, le dimensioni del circuito stampato (PCB, printed circuit board) e i diagrammi dei pinout della scheda. Quello che rende Arduino davvero unico è il suo ambiente di programmazione e questo è l’argomento del Capitolo 5. Questo capitolo definisce il concetto di sketch di Arduino e spiega come si utilizzano il linguaggi C e C++ per creare sketch. Presenta il bootloader di Arduino e la funzione main() di Arduino. Questo capitolo descrive anche come si scarica il codice sorgente di Arduino e come si fa a vedere come si presenta dietro le quinte. Il Capitolo 6 descrive la toolchain AVR-GCC e presenta le tecniche per programmare una scheda Arduino senza utilizzare l’IDE di Arduino. Parla anche dei makefile e include una breve panoramica della programmazione con i linguaggi assembly. Il capitolo passa poi agli strumenti disponibili per caricare il codice su un AVR. Il Capitolo 7 è dedicato alle librerie standard fornite con l’IDE di Arduino. L’IDE di Arduino include numerose librerie e ne vengono continuamente aggiunte di ulteriori. Se
volete sapere se esiste il modulo di una libreria per un determinato sensore o per una specifica operazione, questo è un ottimo punto di partenza. Il Capitolo 8 presenta i vari tipi di shield disponibili per Arduino. Descrive molti dei tipi più comuni, come memorie flash, prototipazione, input/output, Ethernet, Bluetooth, ZigBee, controllo dei servomotori, controllo dei motori passo-passo, schermi di LED e schermi LCD. Spiega anche come si utilizzano diverse shield contemporaneamente e offre alcuni trucchi e suggerimenti per ottenere il massimo da una shield. Il Capitolo 9 descrive alcuni dei vari componenti aggiuntivi disponibili che possono essere utilizzati con Arduino. Questi includono sensori, moduli relè, tastierini numerici e altri elementi che non sono specifici di Arduino, ma che funzionano bene con questa scheda. Per molti degli elementi descritti vengono offerti i dati e gli schermi dei pinout elettrici. A volte semplicemente non è possibile trovare facilmente una shield che serve a fare quello che desideriamo. Il Capitolo 10 descrive i passaggi necessari per crearne una personalizzata. Descrive anche come si utilizza un microcontroller AVR senza una scheda a circuito come Arduino, ma utilizzando comunque l’IDE di Arduino. I Capitoli 11, 12 e 13 mostrano alcuni progetti che illustrano le capacità dei microcontroller AVR e delle schede Arduino. Sono pensati per dimostrare come può essere applicato Arduino in diverse situazioni, non come guide per imparare a costruire una scheda o un dispositivo. Tuttavia, se vi sentite ispirati potete costruire da voi uno qualsiasi degli elementi descritti, che poi vi possono servire come punti di partenza per i vostri progetti personali. La descrizione di ciascun progetto di esempio include la teoria del funzionamento, schemi, un elenco dettagliato dei componenti, i layout delle PCB (se necessario) e una panoramica del software necessario per far funzionare il tutto. Dal momento che questo libro pone l’accento soprattutto sull’hardware di Arduino e sui relativi moduli, sensori e componenti, il software mostrato è pensato soltanto per sottolineare i punti chiave: il mio obiettivo non era presentare esempi completi e pronti per l’utilizzo. I codici completi dei software relativi agli esempi e ai progetti si trovano su GitHub (https://www.github.com/ardnut). Il Capitolo 11 descrive un generatore di segnale semplice e programmabile, un dispositivo pratico da tenere a portata di mano quando si lavora con circuiti elettronici. Con questo progetto, potete generare impulsi a vari cicli di lavoro, emettere una sequenza di impulsi in risposta a un input che la lanci, generare onde sinusoidali e creare anche modelli programmabili di impulsi. Il Capitolo 12 parla della progettazione e della costruzione di un termostato “intelligente”, ideale da utilizzare con un sistema HVAC (riscaldamento, ventilazione e condizionamento dell’aria - heating, ventilation and air conditioning) domestico. Invece di pagare per qualcosa di già costruito e sigillato in un contenitore di plastica, potete costruirvene uno da soli e programmarlo in modo che si comporti esattamente nel modo che desiderate. Vi mostrerò come aggiungervi più di un unico sensore di temperatura: le funzionalità comprendono diversi sensori di temperatura e umidità e l’utilizzo del
ventilatore del vostro sistema HVAC per creare un ambiente confortevole senza bisogno di utilizzare il compressore o di accendere il riscaldamento. Nel Capitolo 13 vedremo come si costruisce un modellino automatico di lanciarazzi con un sequenziatore programmabile e un sistema di controllo automatico. Anche se non disponete di un modellino di lanciarazzi, questo progetto descrive delle tecniche che potete applicare a molti tipi di processi controllati, che sia in una linea di produzione oppure in un dispositivo che gestisce materiale robotico in un laboratorio. L’Appendice A è una panoramica degli strumenti e degli accessori di base dei quali potete aver bisogno se volete andare oltre le schede a circuito e i moduli già pronti. L’Appendice B è una raccolta dei registri di controllo dei microcontroller ATmega168/328, ATmega1280/2560 e ATmega32U4. L’Appendice C è un elenco riepilogativo dei distributori e produttori dei prodotti Arduino e compatibili menzionati in questo libro. Non è affatto esaustivo, ma spero che vi risulterà sufficiente per riuscire a trovare quello che vi serve. L’Appendice D elenca alcuni dei libri consigliati che parlano non soltanto di Arduino, ma anche della programmazione in C e C++ e dell’elettronica in generale. Infine, l’Appendice E è un riepilogo di alcuni degli strumenti di sviluppo software Arduino e AVR facili da trovare. ATTENZIONE Le appendici sono disponibili in lingua originale http://www.tecnichenuove.com/libri/arduino-per-tecnici-ingegneri-e-maker.
in
formato
PDF
all’indirizzo
Riconoscimenti In questo libro, a parte menzionare il team di Arduino e la comunità di Arduino.cc, non appaiono riferimenti specifici a nessuno, almeno non intenzionalmente. Vi ho menzionato diversi produttori e rivenditori di componenti e altri autori, ma ho cercato di essere imparziale e non ne preferisco uno a un altro. Il mio unico criterio nel selezionare quelli che ho menzionato è stato il fatto di possedere uno o più dei loro prodotti e l’essere riuscito a usare una shield, un modulo, un sensore, oppure una PCS Arduino (o in alcuni casi un clone) di un fornitore, anche se soltanto in una dimostrazione di un qualche tipo. Tutti i marchi registrati menzionati sono proprietà dei rispettivi proprietari e qui appaiono soltanto come riferimento. Lo stesso vale per le immagini: ho cercato di utilizzare i miei componenti, strumenti, schede, moduli e altri elementi il più possibile e, anche se in un’immagine può apparire una determinata marca o modello, questo non significa che si tratti dell’unico tipo disponibile, ma soltanto che era quello che possiedo e che utilizzo. In alcuni casi ho utilizzato delle immagini con il permesso del rivenditore o del creatore, opere di dominio pubblico, oppure immagini con licenza Creative Commons (CC) e queste sono contrassegnate come richiesto. I diagrammi, gli schemi e le altre immagini non fotografiche sono tutti di mia creazione e io sono l’unico responsabile di eventuali
errori o omissioni in queste figure.
Convenzioni utilizzate in questo libro In questo libro si utilizzano le seguenti convenzioni tipografiche: Corsivo Indica termini nuovi, URL, indirizzi email, nomi di file ed estensioni di file. Monospaziato
Si utilizza per i codici dei programmi e anche all’interno dei paragrafi per riferirsi a elementi dei programmi come nomi di variabili o di funzioni, database, tipi di dati, variabili d’ambiente, dichiarazioni e parole chiave. Monospaziato corsivo
Indica testi che devono essere sostituiti da valori forniti dall’utente o da valori determinati dal contesto.
Come contattarci Per inviare all’editore commenti e domande relativi a questo libro: Tecniche Nuove Spa Via Eritrea, 21 20157 Milano Esiste anche una pagina web (in inglese) dedicata al libro, contenente errata corrige, esempi e ulteriori informazioni. L’indirizzo della pagina è: http://bit.ly/arduino-a-technical-reference. Per domande tecniche o commenti sul libro, inviate un’email a:
[email protected].
Ringraziamenti Questo libro non sarebbe stato possibile senza la pazienza e il sostegno della mia famiglia. Scrivere sembra causare assuefazione, ma loro mi hanno incoraggiato e sostenuto e mi portavano perfino da mangiare e venivano a controllare che fossi ancora vivo nel mio ufficio. Non si può chiedere di meglio. Vorrei ringraziare specialmente mia figlia Seren per il suo aiuto fotografico e nel mantenere catalogata e organizzata la mia raccolta di bit. Vorrei anche ringraziare lo staff editoriale di O’Reilly per avermi offerto l’opportunità di lavorare di nuovo con loro. Come sempre, sono stati di grande aiuto, pazienti e disposti a scommettere su di me. Un grazie speciale va a Brian Sawyer e a
Dawn Schanafelt per il loro eccellente sostegno editoriale e per le loro indicazioni, e a Mike Westerfield per la sua acuta revisione tecnica del materiale.
1 Se scrivete “Arduino” nel campo di ricerca su eBay, vi appariranno moltissime cose come sensori di prossimità a ultrasuoni, sensori di temperatura e umidità, vari cloni di Arduino, shield Bluetooth e ZigBee e molto altro ancora. Ma, purtroppo, alcuni di questi prodotti sono accompagnati da una documentazione scarsa o nulla e, anche se ne presentano una, questa potrebbe non essere molto aggiornata o precisa. Questo non significa che non dobbiate acquistarli (i prezzi presso questi rivenditori sono di solito ottimi e la qualità della costruzione generalmente molto buona), ma, come sempre quando si acquista qualcosa online, caveat emptor. 2 I libri Environmental Monitoring with Arduino e Atmospheric Monitoring with Arduino (O’Reilly), entrambi di Emily Gertz e Patrick Di Justo, suggeriscono alcune buone idee per fare quello che dicono i titoli con questi sensori economici e facili da trovare e una scheda Arduino.
1 La famiglia di Arduino
Questo capitolo presenta una breve storia di Arduino, descrivendo una concisa genealogia dei vari tipi di scheda che sono stati creati a partire dal 2007. Non parla delle schede che sono state prodotte prima del 2007, né cerca di offrire una panoramica completa dei vari cloni e derivati che sono stati prodotti. Qui l’obiettivo principale è individuare le differenze tra i vari tipi principali di schede Arduino, prestando particolarmente attenzione ai tipi di processori utilizzati e al design fisico delle schede. Qui daremo anche rapidamente un’occhiata alla gamma di applicazioni possibili delle schede a circuito Arduino. Il Capitolo 2 offrirà informazioni generali sulle funzioni interne dei processori Atmel AVR e il Capitolo 3 parlerà dei processori specifici utilizzati sulle schede Arduino. Con l’eccezione della Yún, il Capitolo 4 descriverà le caratteristiche fisiche delle varie schede Arduino ufficiali presentate in questo capitolo.
Una breve storia Nel 2005, basandosi sul lavoro di Hernando Barragán (il creatore di Wiring), Massimo Banzi e David Cuartielles hanno creato Arduino, un dispositivo programmabile e facile da utilizzare per progetti di design interattivo, presso l’Interaction Design Institute Ivrea a Ivrea, in Italia. David Mellis ha svilupppato il software di Arduino, che si basa su Wiring. Presto, Gianluca Martino e Tom Igoe si sono uniti al progetto e loro cinque sono conosciuti come i fondatori originali di Arduino. Quello che volevano ottenere era un dispositivo che fosse semplice, facile da collegare a varie cose (come relè, motori e sensori) e semplice da programmare. Volevano anche che fosse economico, dal momento che è noto che studenti e artisti non dispongono di grossi risparmi. Quindi hanno scelto la famiglia AVR di microcontroller da 8 bit (MCU o µC) di Atmel e hanno progettato una scheda a circuito indipendente con connessioni facili da utilizzare, hanno scritto il firmware del bootloader del microcontroller e hanno raccolto il tutto in un semplice IDE (ambiente di sviluppo integrato) che utilizzasse programmi di nome “sketch”. Il risultato è stato Arduino. Da allora, Arduino è cresciuto in varie direzioni: alcune versioni sono diventate più piccole dell’originale, mentre altre più grosse. Ciascuna di esse è pensata per una
specifica nicchia. L’elemento comune tra tutte è la libreria di runtime AVR-GCC di Arduino, che viene fornita con l’ambiente di sviluppo di Arduino, e il firmware del bootloader sulla scheda, che è già precaricato sul microcontroller di tutte le schede Arduino. La famiglia di schede Arduino utilizza processori sviluppati dall’Atmel Corporation di San Jose, in California. Quasi tutti i design di Arduino utilizzano la serie di microcontroller AVR da 8 bit. L’eccezione principale è rappresentata dal Due, con il suo processore ARM Cortex-M3 da 32 bit. In questo libro non parleremo del Due, dal momento che è radicalmente diverso dai dispositivi AVR in molti modi fondamentali e realmente merita una descrizione separata e dedicata a lui e ai microcontroller simili basati sul design ARM Cortex-M3. Anche se la scheda Arduino è, come dichiara il team di Arduino, semplicemente una scheda di sviluppo Atmel AVR di base, quello che fa la differenza è l’ambiente software di Arduino. Questo rappresenta l’esperienza comune di tutti gli utenti di Arduino e la pietra angolare del concetto che ne sta alla base. Nel Capitolo 5 vedremo l’IDE di Arduino, le librerie fornite con l’IDE e il bootloader. Nel Capitolo 6 descriveremo il processo di creazione del software su una MCU AVR senza utilizzare l’IDE di Arduino.
Tipi di dispositivi Arduino Nel corso degli anni, i designer di Arduino.cc hanno sviluppato diversi design della scheda. La prima scheda Arduino che è stata ampiamente distribuita, la Diecimila, è stata rilasciata nel 2007 e dal suo rilascio iniziale la famiglia di Arduino si è sviluppata in modo da approfittare dei vari tipi di dispositivi Atmel MCU AVR. Il Due, rilasciato nel 2012, è il primo Arduino a utilizzare un processore ARM Cortex-M3 da 32 bit e provoca una rottura con il resto della famiglia per quanto riguarda la potenza di elaborazione e la configurazione del pinout sulla scheda. Anche altre schede, come la LilyPad e la Nano, non presentano lo stesso pinout degli altri membri della famiglia e sono pensate per una gamma diversa di applicazioni: cose da indossare nel caso del LilyPad, dispositivi palmari nel caso della Esplora e oggetti molto piccoli nel caso del Mini, del Micro e del Nano. Ogni anno che passa appaiono nuovi tipi di schede Arduino, per cui l’elenco presentato qui potrebbe non risultare più aggiornato quando lo leggerete. Le versioni più recenti sono dotate di processori più avanzati con molta più memoria e funzionalità input/output (I/O) migliorate, ma per lo più utilizzano gli stessi pinout e funzionano con le schede aggiuntive già esistenti, dette shield, e con vari componenti aggiuntivi come sensori, relè e attuatori. La Tabella 1-1 elenca i tipi di Arduino che sono apparsi a partire dal 2005. Sulle versioni più recenti di Arduino funzioneranno anche la maggior parte degli sketch creati per i modelli più vecchi, magari con meno regolazioni e librerie più nuove, mentre gli sketch scritti per le versioni più recenti possono funzionare o meno sui modelli più vecchi.
Tabella 1-1 - Timeline dei prodotti Arduino.
Scheda
Anno
Microcontroller
Scheda
Anno
Microcontroller
Diecimila
2007
ATmega168V
Mega 2560
2010
ATmega2560
LilyPad
2007
ATmega168V/ATmega328V
Uno
2010
ATmega328P
Nano
2008
ATmega328/ATmega168
Ethernet
2011
ATmega328
Mini
2008
ATmega168
Mega ADK
2011
ATmega2560
Mini Pro
2008
ATmega328
Leonardo
2012
ATmega32U4
Duemilanove
2008
ATmega168/ATmega328
Esplora
2012
ATmega32U4
Mega
2009
ATmega1280
Micro
2012
ATmega32U4
Fio
2010
ATmega328P
Yún
2013
ATmega32U4 + Linino
La Tabella 1-1 non è una guida per l’acquisto, ma il suo scopo è offrire un certo contesto storico di Arduino. Come potete vedere, negli anni 2007 e 2008 abbiamo visto l’introduzione del LilyPad, delle schede dal fattore forma più ridotto come la Nano, la Mini e la Mini Pro, e l’introduzione del Duemilanove come passaggio evolutivo naturale basato sul Diecimila. Anche se tra il Diecimila e il Duemilanove non ci sono differenze fisiche significative, il Duemilanove incorpora alcuni miglioramenti per quanto riguarda l’alimentazione, soprattutto il switchover automatico tra l’alimentazione USB o con la corrente DC esterna (corrente diretta). Le versioni più recenti del Duemilanove utilizzano anche la MCU ATmega328, che offre più memoria ai programmi. La Tabella 1-1 non include l’Arduino Robot, che è una PCB con motori e ruote collegate. Una delle schede più recenti nella famiglia di Arduino è la Yún, un dispositivo interessante dotato del microcontroller ATmega32U4 e anche di un modulo Linino con processore Atheros AR9331 basato su MIPS capace di eseguire una versione del sistema operativo OpenWrt basato su Linux. Non mi spingerò fino a parlare dell’aspetto OpenWrt della Yún, ma fondamentalmente la parte Arduino è semplicemente un Arduino standard (un Leonardo, per essere specifici). Se volete sapere si più sulla scheda Yún, vi consiglio di consultare sito web di Arduino (https://www.arduino.cc/en/Main/ArduinoBoardYun). Quando nella Tabella 1-1 appare più di un microcontroller, significa che quella determinata versione di scheda Arduino all’inizio era prodotta con un microcontroller e successivamente con l’altro dispositivo, di solito dotato di maggiori capacità. Per esempio, una versione più vecchia del Duemilanove avrà un ATmega168, mentre i modelli più nuovi hanno un ATmega328. Dal punto di vista della funzionalità, l’ATmega168 e l’ATmega328 sono identici, ma l’ATmega328 è dotato di più memoria interna.
Le ultime aggiunte nella famiglia di Arduino, la Leonardo, la Esplora, la Micro e la Yún, utilizzano tutte l’ATmega32U4. Questo, pur essendo simile all’ATmega328, prensenta anche un componente integrato che è l’interfaccia USB-seriale e che elimina uno dei circuiti integrati (IC, integrated circuit) che si trovano sulle schede come la Uno e la Duemilanove. Inoltre, l’interfaccia di programmazione si comporta in modo leggermente differente con le schede che utilizzano l’ATmega32U4, ma per la maggior parte degli utenti questo dovrebbe risultare ampiamente trasparente. Il Capitolo 2 descriverà il funzionamento generale dei microcontroller AVR, il Capitolo 3 contiene le descrizioni dei tipi specifici di MCU AVR che si trovano sui dispositivi Arduino e il Capitolo 4 offrirà le descrizioni delle principali schede a circuito Arduino e le definizioni dei loro pinout.
Gallerie di Arduino Le Tabelle dalla 1-1 alla 1-5 mostrano alcuni dei vari tipi di schede Arduino, sia del passato che del presente. Non li includono tutti, dal momento che periodicamente vengono aggiunti nuovi tipi o aggiornamenti a quelli esistenti. Le immagini che seguono mostrano la vasta gamma di forme fisiche e applicazioni pensate per Arduino. Dal punto di vista fisico, un Arduino non è una scheda a circuito grande. Le schede di base, la cui disposizione fisica dei pin di solito è pensata per le schede aggiuntive (dette shield e descritte nel Capitolo 8), misurano 2,1 per 2,7 pollici (53,3 per 68,6 mm). La Figura 1-1 mostra una selezione di schede Arduino con accanto un righello, mentre la Figura 1-2 mostra una scheda Nano montata su una breadboard che non richiede saldature.
Figura 1-1 - Le dimensioni relative delle schede Arduino.
Figura 1-2 - Una scheda Arduino Nano su una breadboard che non richiede saldature.
Il Capitolo 4 contiene disegni di riferimento con le dimensioni e le definizioni dei pin della maggior parte delle schede Arduino più comuni. Notate che, pur essendo molto piccola, una scheda come la Nano ha tutte le stesse capacità della Duemilanove, eccetto per i comodi pin socket e il normale connettore USB (tipo B). È ideale per applicazioni dove non deve essere disturbata dopo la sua installazione e dove sono necessarie le sue dimensioni ridotte. Alcune applicazioni che vengono subito in mente sono dispositivi autonomi di raccolta di dati ambientali (stazioni meteorologiche autonome a energia solare oppure boe per raccogliere dati negli oceani, per esempio), timing e raccolta di dati per modellini di razzi, sistemi di sicurezza e magari perfino una caffettiera “intelligente”. Tabella 1-2 - Il layout delle schede Arduino di base.
Tipo
Anno di introduzione Diecimila
2007
Duemilanove
2008
Uno (versione R3)
2010
Ethernet
2011
Leonardo
2012
Tabella 1-3 - Il layout delle schede Arduino Mega.
Tipo
Anno di introduzione Mega
2009
Mega 2560
2009
Mega ADK
2011
Tabella 1-4 - Le schede Arduino con un fattore di forma ridotto.
Tipo
Anno di introduzione Nano
2008
Mini
2008
Fio
2010
Micro
2012
Tabella 1-5 - Le schede Arduino con un fattore di forma speciale.
Tipo
Anno di introduzione
LilyPad
2007
Esplora
2012
I dispositivi compatibili con Arduino Oltre ai vari tipi di schede progettati o approvati da Arduino.cc, esistono molti dispositivi che sono compatibili con il suo hardware oppure con il suo software. Quello che rende questi dispositivi compatibili con Arduino è il fatto che incorporino il bootloader di Arduino (oppure qualcosa che funzioni in modo simile) e che possano essere programmati con l’IDE di Arduino selezionando il tipo giusto di scheda Arduino compatibile nella casella combinata dell’IDE.
I dispositivi compatibili con l’hardware Un dispositivo compatibile con l’hardware di Arduino è un dispositivo dove i vari pin I/O della scheda sono stati disposti in modo da corrispondere a uno dei fattori di forma di Arduino esistenti. Una scheda compatibile con hardware (di solito) può accettare una qualsiasi delle shield e dei moduli aggiuntivi creati per le schede Arduino ufficiali. Il motivo che sta dietro è spiegato in “Le convenzioni per la nomenclatura di Arduino” a pagina 10. Nella maggior parte dei casi, le schede compatibili con l’hardware hanno un aspetto molto simile a quello delle schede Arduino, a eccezione che per il fatto che non presentano il logo e la serigrafia ufficiali di Arduino. Altri prodotti compatibili con l’hardware possono non assomigliare affatto alle tipiche schede Arduino, ma offrire i pin socket nella disposizione corretta per permettere di utilizzare una shield standard per Arduino. Alcuni prodotti compatibili con l’hardware includono ulteriori connessioni, come la versione SainSmart della Uno con ulteriori connettori per le funzioni I/O. La Tabella 16 elenca alcuni cloni di Arduino e alcune schede compatibili che sono disponibili. Ne esistono molti altri, rispetto a quelli mostrati qui, ma questi dovrebbero bastare a farvi un’idea di quello che avete a vostra disposizione. Tabella 1-6 - I dispositivi compatibili con l’hardware di Arduino.
Nome
Tipo
Origine
SainSmart UNO
Clone dell’UNO
Cina
SainSmart Mega2560
Clone del Mega 2560
Cina
Brasuino
Simile alla Uno, con piccole modifiche
Brasile
Kit clone
Diavolino
compatibile con il layout di Arduino
USA
Notate che il Diavolino è un kit e richiede montaggio.
I dispositivi compatibili con il software Esistono molte schede compatibili con il software di Arduino. Queste utilizzano il bootloader e l’ambiente di sviluppo di Arduino, ma non presentano un fattore di forma fisico completamente compatibile con Arduino. I dispositivi compatibili con il software possono essere programmati con gli strumenti di sviluppo di Arduino, ma possono utilizzare disposizioni diverse dei pin I/O, oppure magari utilizzare alcuni altri tipi di connettori anziché i pin socket che si trovano sulle normali schede Arduino. I circuiti personalizzati basati su microcontroller AVR e costruiti in un dispositivo o sistema più grande possono ricadere nella categoria dei dispositivi compatibili con il software se nel microcontroller è installato il bootloader di Arduino. Il cuore di Arduino sono il processore e il bootloader preinstallato. Utilizzando questa definizione, si potrebbe avere soltanto un ATmega AVR IC con il firmware di Arduino caricato. Si potrebbe quindi utilizzarlo con una breadboard che non richiede saldature e l’ambiente di sviluppo di Arduino. Presso diverse fonti è possibile acquistare MCU AVR IC con il codice del bootloader pecaricato, oppure è possibile farsene uno da soli. Nel Capitolo 5 vedremo i passaggi necessari per caricare il firmware del bootloader di Arduino su una MCU AVR. È interessante notare che alcune delle schede Arduino, come la Mini, la Micro, la Nano, la LilyPad e la Esplora, non sono compatibili con l’hardware nel senso che non utilizzano il layout di connessioni I/O “standard”. Non possono essere utilizzate direttamente con una shield convenzionale, ma sono comunque schede Arduino e sono supportate dall’IDE di Arduino. Un esempio di dispositivo compatibile con il software di Arduino è la scheda Boarduino di Adafruit Industries. Questa scheda è progettata per essere montata su una breadbord senza saldature standard, come un IC completo da 40 pin. È disponibile in due stili: DC e USB. La versione DC non dispone di un chip USB integrato e quindi per programmarla è necessario un adattatore USB esterno. Un altro esempio di scheda compatibile con il software è la Dragonfly di Circuit Monkey, che utilizza connettori standard tipo Molex anziché i pin e i socket utilizzate sulle schede Arduino convenzionali. È pensata per ambienti ad alta vibrazione, come gli UAV (unmanned aerial vehicles) e la robotica. La scheda Raspduino è pensata per essere montata su una scheda Raspberry Pi e funziona in modo equivalente all’Arduino Leonardo. Questo produce una combinazione equivalente alla Yún, ma non esattamente uguale. Ciascuna configurazione ha i suoi punti di forza e i suoi punti di debolezza. La Tabella 1-7 elenca alcune schede compatibili
con il software di Arduino. Tabella 1-7 - I dispositivi compatibili con il software di Arduino.
Nome
Descrizione
Origine
Boarduino DC
Progettata per adattarsi a una breadboard che non richiede saldature
USA
Boarduino USB
Progettata per adattarsi a una breadboard che non richiede saldature
USA
Dragonfly
Utilizza connettori di tipo Molex per I/O
USA
Raspduino
Progettata per adattarsi su una scheda Raspberry Pi
Paesi Bassi
Quella presentata non è che una piccola selezione delle varie schede che sono disponibili. Dal momento che il microcontroller AVR è facile da integrare in un design, viene utilizzato in numerose applicazioni. Con il firmware del bootloader di Arduino, programmare un dispositivo è diventato davvero molto più semplice e le possibilità di design sono innumerevoli.
Le convenzioni per la nomenclatura di Arduino Nonostante il design dei circuiti e il software di Arduino siano open source, il team di Arduino ha riservato l’utilizzo del termine “Arduino” ai suoi design e il logo di Arduino è un marchio registrato. Per questo motivo, a volte troverete cose che si comportano e si presentano come dispositivi Arduino ufficiali, ma che non presentano la marca Arduino e che non sono state prodotte dal team di Arduino. Alcune di loro nel nome del prodotto contengono i suffissi “-duino” o “-ino”, come Freeduino, Funduino, Diavolino, Youduino e così via. Alcune, come le schede di SainSmart, utilizzano proprio il nome del modello (Uno e Mega2560, per esempio). NOTA Mentre scrivevo questo libro era in corso una disputa tra la società creata dai fondatori originali (Arduino LLC) e un’altra società avviata da uno dei fondatori originali (Arduino SRL). Di conseguenza, Arduino LLC utilizza il marchio
registrato Arduino negli Stati Uniti e Genuino altrove.
Occasionalmente, alcuni producono una scheda che dichiara di essere Arduino, ma in realtà non è che una copia che utilizza il marchio registrato di Arduino senza permesso. Anche la serigrafia utilizzata per aggiungere il logo e altre informazioni sulle schede Arduino ufficiali è protetta da copyright e il team di Arduino non la rilascia con il file del layout delle PCB. Sul suo blog, Massimo Banzi ha una sezione (http://www.massimobanzi.com/) dedicata esattamente a queste schede non autorizzate e il suo esame delle copie palesi e spudorate è a dir poco interessante. Vi basta cercare il tag “hall of shame”. Qui il concetto fondamentale è che chiunque è benvenuto se vuole copiare gli schemi, il codice del bootloader e l’IDE di Arduino, e utilizzarli per creare una versione personalizzata di Arduino. Dopo tutto, si tratta di un progetto open source. Quello che non è consentito è chiamarlo Arduino oppure utilizzare l’immagine di Arduino.cc senza permesso.
Che cosa posso fare con Arduino? Oltre alla possibilità di programmare facilmente offerta dall’IDE di Arduino, l’altra caratteristica importante di Arduino è la potenza e la capacità del microcontroller AVR sul quale si basa. Con una manciata di shield aggiuntive facili da reperire (descritte nel Capitolo 8) e una vesta selezione di sensori e attuatori a basso prezzo (che saranno descritti nel dettaglio nel Capitolo 9), c’è davvero ben poco che non si possa fare con Arduino, a condizione che si tengano a mente alcuni limiti fondamentali. Il primo limite è la memoria. L’MCU AVR non offre molta memoria dove salvare programmazione e variabili e molti dei componenti AVR non permettono di aggiungerne di ulteriori. Detto questo, i tipi ATmega32 e ATmega128 possono utilizzare memoria esterna, ma poi le funzioni I/O di questi pin cessano di essere immediatamente disponibili. Le schede Arduino non sono state progettate per accogliere memoria esterna, dal momento che nel progetto di base si è dato per scontato che il chip AVR di per sé avrebbe offerto gli I/O necessari e l’utente vi avrebbe eseguito un programma relativamente corto. L’Arduino non è stato pensato come alternativa a un sistema informatico completo con gigabyte di RAM e un hard disk (HDD, hard disk drive). Esistono alcuni computer economici, basati su Intel e con un un’unica scheda, che corrispondono a questa descrizione, ma che non starebbero dentro a una scatoletta di mentine, a un pezzo di tubo PVC attaccato a un palo o a un albero, a un piccolo robot, o in una sezione di un modellino di lanciarazzi. Arduino sì. Il secondo limite è la velocità. La velocità di clock della CPU di Arduino di solito è compresa tra 8 e 20 MHz (nel Capitolo 4 troverete un confronto dettagliato dei tipi di dispositivi AVR di Arduino). Anche se può sembrare lento, dobbiamo tenere presente due fattori chiave: il primo è che l’AVR è il design di un RISC (reduced instruction set computer) molto efficiente e il secondo è che le cose nel mondo reale in genere non
avvengono molto velocemente dal punto di vista di un microcontroller. Per esempio, quanto spesso un termostato cosiddetto intelligente deve campionare la temperatura in una casa o in un ufficio? Una volta al secondo è probabilmente un’esagerazione e una volta ogni 5 o perfino10 secondi andrà benissimo. Quanto spesso un robot deve emettere un impulso a ultrasuoni per determinare se davanti c’è un ostacolo? Un impulso ogni 100 ms probabilmente è più che sufficiente (a meno che il robot non proceda molto, molto rapidamente). Quindi, nel caso di un Arduino a 16 MHz (come il Leonardo, per esempio), tra gli impulsi del sensore si produrranno circa 1.000.000 o più di tick del clock della CPU, a seconda di cos’altro sta facendo la CPU con gli impulsi. Dato che in un uno o due cicli del clock un AVR può eseguire molte istruzioni, tra ciascun impulso del sensore a ultrasuoni e l’altro rimane disponibile molta attività della CPU. Il terzo limite principale è l’alimentazione elettrica. Dal momento che l’hardware di Arduino in realtà non è altro che una PCB su cui risiede un IC AVR, tra il microcontroller e il mondo esterno non c’è un buffer. Se non facciamo attenzione a non far scorrere più corrente di quella che il dispositivo può gestire, rischiamo rapidamente di bruciare un AVR (in altre parole, di surriscaldare l’IC e distruggerlo). Dobbiamo tenere presente anche il voltaggio, dal momento che alcuni tipi di AVR hanno I/O da 3,3 V, mentre altri sopportano 5 V. Collegare un TTL (transistor-transistor logic) da 5 V a un dispositivo da 3,3 V di solito provoca danni all’hardware e così si rischia di bruciarlo. Tenendo in mente i limiti che abbiamo appena descritto, ecco alcune possibili applicazioni per Arduino: •
Monitoraggio nel mondo reale – Stazione meteorologica automatica – Rilevatore di fulmini – Monitoraggio del sole per pannelli solari – Monitor di radiazioni in background – Rilevatore automatico di fauna selvatica – Sistema di sicurezza domestico o aziendale
•
Controllo a piccola scala – Piccoli robot – Modellini di razzi – Modellini di aerei – UAV quadrirotori – CNC semplice per piccole machine – Automazione a piccola scala – Serra automatica
– Acquario automatico – Robot porta campioni da laboratorio – Camera termica di precisione – Sistema di test automatizzato elettronico •
Performance artistica – Controllo dinamico dell’illuminazione – Controllo dinamico della sonorizzazione – Strutture cinematiche – Opere che reagiscano al pubblico
Nei Capitoli 11, 12 e 13 vedremo applicazioni come un termostato intelligente, un generatore di segnale programmabile e un sistema di controllo automatico per lanciare razzi che vi aiuti a realizzare le vostre aspirazioni suborbitali. E questi non sono che la punta dell’iceberg. Le possibilità sono vaste e sono limitate soltanto dalla vostra immaginazione. Se non cercate di chiedere ad Arduino di fare qualcosa che dovrebbe fare un computer completo, potete integrarlo in applicazioni interessanti di ogni tipo, che è esattamente quello che avevano in mente i ragazzi di Arduino.cc.
Per maggiori informazioni Le schede elencate in questo capitolo non sono che una breve selezione di tutte quelle disponibili e anche la storia Arduino è molto più ricca di dettagli. Se digitate “Arduino” nel campo di ricerca di Google, otterrete migliaia di risultati da esplorare. Il sito ufficiale di Arduino si trova su http://www.arduino.cc. Il blog di Massimo Banzi si trova su http://www.massimobanzi.com. Inoltre, trovate i link di altri siti e libri consigliati nelle Appendici.
2 Il microcontroller AVR
Dal momento che un Arduino basato su AVR in realtà è soltanto una piattaforma fisica per un microcontroller AVR (cioè, una scheda breakout), le caratteristiche elettriche di Arduino sono essenzialmente quelle di un dispositivo AVR sulla PCB. Capire i dettagli di basso livello di un Arduino significa in realtà capire il dispositivo AVR che ne sta alla base. Da questo punto di vista, questo capitolo presenta materiale di ampia applicazione che consiste nelle descrizioni di alto livello delle funzioni principali utilizzate dalla famiglia AVR. Questo comprende la CPU dell’AVR e le cosiddette funzioni periferiche come timer, contatori, la logica dell’interfaccia seriale, convertitori analogodigitale (A/D), comparatori analogici e porte I/O digitali e discrete. I microcontroller AVR sono disponibili in una vasta gamma di tipi di configurazioni e pacchetti, il che rende una sfida scrivere un capitolo come questo. Fortunatamente, i vari tipi di dispositivi AVR da 8 bit utilizzano una CPU (central processing unit) comune e un’architettura interna modulare costruita intorno a un bus di dati interno. Questo permette a ciascuna variante di incorporare diverse combinazioni e quantità di moduli funzionali nei circuiti interni dell’AVR, per rispondere a esigenze specifiche di design e supportare diverse applicazioni. Per via dei limiti pratici di spazio, le descrizioni in questo capitolo sono necessariamente concise e concentrate sulle caratteristiche fondamentali. Inoltre, non forniscono molti dei dettagli di basso livello che si possono trovare nella documentazione di riferimento messa a disposizione da Atmel (http://www.atmel.com). Se avete bisogno o desiderio di conoscere il circuito logico e i dettagli a livello di registro di quello che contiene un particolare microcontroller AVR, Atmel mette a vostra disposizione gratuitamente schede tecniche, guide per l’utente e note applicative.
La storia Il microcontroller AVR ha preso vita all’inizio degli anni ’90 nella forma del progetto di uno studente presso il Norwegian Institute di Technology. Due studenti, Alf-Egil Bogen e Vegard Wollan, hanno concepito un dispositivo da 8 bit con un’architettura interna di tipo RISC mentre lavoravano presso il semiconduttore locale a Trondheim, in Norvegia. Più tardi, il progetto è stato venduto ad Atmel, dove Bogen e Wollan hanno continuato a
lavorarci e a perfezionarlo. I microcontroller AVR sono altamente configurabili e molto versatili e includono diverse caratteristiche uniche che li distinguono da altri microcontroller da 8 bit come i componenti 8051 o 68HC05. L’AVR è un microcontroller RISC da 8 bit con architettura Harvard modificata. In un programma di sola lettura con architettura Harvard, il codice e i dati modificabili (variabili) sono salvati in spazi di memoria separati. Per fare un confronto, un microprocessore come il 68040 utilizza l’architettura Von Neumann, nella quale i programmi e i dati condividono lo stesso spazio di memoria. La famiglia di dispositivi AVR è stata una delle prime a incorporare la memoria flash per l’archiviazione dei programmi, al posto di una ROM che si può programmare una sola volta (memoria di sola lettura), di una EPROM (memoria di sola lettura che si può programmare e cancellare) o di una EEPROM (memoria di sola lettura che si può programmare e cancellare elettricamente) come su altri microcontroller. Questo permette di riprogrammare un microcontroller AVR semplicemente caricando il codice di un nuovo programma sulla memoria flash interna del dispositivo. Molti componenti AVR dispongono di una piccola quantità di EEPROM per archiviare cose come parametri operativi che devono persistere quando avvengono modifiche sulla memoria flash.
L’architettura interna Internamente, un microcontroller AVR ATmega consiste in una CPU AVR e varie funzioni di input/output, timing, conversione analogico-digitale, contatore/timer e interfaccia seriale, insieme ad altre funzioni a seconda del numero dei componenti. Queste vengono definite da Atmel funzioni periferiche. Oltre alle funzioni I/O, le differenze principali tra i tipi di microcontroller sta nella quantità di memoria flash integrata e di funzioni I/O disponibili. I componenti da 8 bit utilizzano tutti essenzialmente lo stesso core della CPU AVR. Ecco un elenco che mostra alcune delle caratteristiche principali dei microcontroller AVR: •
Architettura RISC – 131 istruzioni – 32 registri da 8 bit per scopi generali – Clock rate fino a 20 MHz (20 MIPS)
•
Memoria integrata – Memoria flash programmabile (fino a 256K) – EEPROM integrata (fino a 4K) – SRAM interna (fino a 32K)
•
Tensione di esercizio
– VCC = da 1,8 a 5,5 V DC La Figura 2-1 mostra un diagramma a blocchi semplificato del core della CPU dell’AVR che si trova sui dispositivi AVR da 8 bit. La Figura 2-2 mostra un diagramma a blocchi generico e di alto livello di un dispositivo AVR. Il suo scopo non è rappresentare un dispositivo AVR specifico, ma soltanto un AVR in generale.
Figura 2-1 - Il diagramma a blocchi della CPU dell’AVR.
Figura 2-2 - Il diagramma a blocchi di un microcontroller AVR.
Le funzioni periferiche sono controllate dalla CPU per mezzo di un bus di dati interno ad alta velocità. I registri di controllo (separati dai registri della CPU) si utilizzano per configurare l’operazione delle periferiche. Tutte le funzioni periferiche condividono i pin delle porte con le funzionalità I/O digitali e discrete. Atmel produce molti tipi diversi di microcontroller AVR, cosa che permette ai designer di hardware di scegliere il componente che risponde alle loro esigenze specifiche e che riduce il numero di pin non utilizzati e di spazio sprecato su una scheda a circuito stampato. Alcuni, come i componenti tinyAVR, sono piccoli contenitori a montaggio superficiale con soltanto sei pin. Ciascuno ha una o più porte digitali I/O discrete, che possono essere programmate per eseguire diverse funzioni (“Le funzioni periferiche”). Per esempio, l’ATTINY13-20SQ si presenta come un contenitore a montaggio superficiale con DIP (dual in-line pin) o un SOIC (small-outline IC) da otto pin. Sei dei pin del dispositivo sono collegati a una porta I/O interna da 8 bit (porta B). Gli altri due sono VCC (alimentazione) e messa a terra. I sei pin della porta B possono essere configurati come input analogici, output dell’oscillatore, input dell’interrupt, segnali dell’SPI, oppure input o output digitali discreti. Internamente, il dispositivo (anche quelli più piccoli) è comunque un microcontroller AVR, dotato di una memoria flash integrata da 1K per i
programmi e 64 byte di RAM per le variabili. All’altra estremità dello spettro ci sono i componenti AVR come l’ATmega649, con nove porte da 8 bit (da A a J, ma senza la I, dal momento che la lettera I può essere confusa con il numero 1), 64K di memoria flash, 4K di RAM, 2K di EEPROM, 54 pin I/O per scopi generali e un’interfaccia LCD integrata. La serie di componenti AVR32 è formata da processori AVR da 32 bit con fino a 256K di memoria flash, 32K di RAM, un’unità DSP (digital signal processing) integrata, memoria protetta e 36 pin I/O per scopi generali. Nessuna scheda Arduino utilizza un componente AVR piccolo come il tinyAVR (comprimere il bootloader di Arduino in qualcosa con soltanto 1K di memoria flash disponendo ancora di spazio per un programma utile sarebbe davvero una sfida) o come l’ATmega649 o l’AVR32, ma qui la questione è che la famiglia AVR offre molte scelte e i componenti che sono stati scelti per essere utilizzati nei dispositivi Arduino non sono gli unici componenti AVR che si possono utilizzare.
La memoria interna Tutti i dispositivi AVR contengono varie quantità di tre tipi di memoria: flash, SRAM (static random-access memory) ed EEPROM. La memoria flash si utilizza per salvare il codice dei programmi, la SRAM si utilizza per contenere dati transitori come le variabili e gli stack dei programmi, mentre la EEPROM può contenere dati che devono persistere nonostante i cambiamenti del software e i riavvii. Le memorie flash ed EEPROM possono essere caricate esternamente ed entrambe conservano i loro contenuti quando l’AVR viene spento. La SRAM è volatile e i suoi contenuti vengono persi quando l’AVR perde l’alimentazione.
Le funzioni periferiche Il cuore di un microcontroller AVR è la CPU da 8 bit, ma quello che lo rende un microcontroller davvero utile sono le funzioni periferiche integrate nell’IC con la logica della CPU. Le funzioni periferiche di un dispositivo AVR variano a seconda del tipo. Alcune dispongono di un timer, altre ne hanno due o più (fino a sei nel caso di alcuni tipi). Altri componenti possono disporre di un convertitore A/D (ADC) da 10 bit, mentre altri di un convertitore da 12 bit. Tutti i componenti AVR mettono a disposizione pin I/O bidirezionali per segnali digitali discreti. Alcune versioni, inoltre, supportano un touchscreen e altri tipi di interfacce interattive. Questo paragrafo contiene descrizioni generali delle funzioni periferiche utilizzate sui vari tipi di dispositivi AVR che si trovano sui prodotti Arduino, con l’ATmega168 come esempio di base. Questo paragrafo non cerca di offrire un riferimento esaustivo di tutti i
tipi di microcontroller AVR, ma descrive la funzionalità generale di ciascun tipo di funzione periferica. Nel Capitolo 3 trovate informazioni specifiche sui processori che si utilizzano sulle schede Arduino descritte in questo libro. Inoltre, potete trovare i dettagli di basso livello che non forniamo qui nella documentazione tecnica di Atmel.
I registri di controllo Oltre che dei 32 registri di scopo generale della CPU, i dispositivi AVR dispongono anche di diversi registri di controllo che determinano come devono comportarsi le porte I/O, i timer, le interfacce di comunicazione e altre funzionalità. La configurazione dei registri di controllo cambia a seconda del tipo di dispositivo, dal momento che diversi tipi possono disporre di più o meno porte rispetto ad altri e di diverse configurazioni delle funzioni periferiche. I registri di controllo dei componenti AVR utilizzati sulle schede Arduino descritte in questo libro si trovano nell’Appendice B. Sono descritti nel dettaglio anche nella documentazione messa a disposizione direttamente da Atmel. Perfino un componente AVR modesto come l’ATmega168 ha molte più funzionalità interne di quanti pin non abbia a disposizione da dedicare a ciascuna funzione. Per questo motivo, la maggior parte dei pin dei microcontroller AVR possono essere configurati in modo che eseguano funzioni specifiche in base alle configurazioni contenute nei registri di controllo. Dal momento che le funzioni dei pin possono essere configurate dinamicamente, è possibile fare in modo che un pin esegua un tipo di funzione a un certo punto e poi una diversa una volta che il valore del registro di controllo viene modificato. Per esempio, il pin 12 dell’ATmega168 in un package (contenitore) DIP da 28 pin è collegato a PD6 (Porta D, bit 6), ma può essere configurato anche in modo che si comporti come un sorgente di interrupt (PCINT22), come l’input positivo del comparatore analogico interno dell’AVR (AIN0), oppure come l’output di un circuito logico del comparatore del timer (l’output Timer/Counter0 corrisponde ad A), che può essere utilizzato per generare un segnale PWM (Pulse Width Modulation).
Le porte I/O digitali Per comunicare con il mondo esterno, i microcontroller AVR utilizzano porte I/O bidirezionali. Una porta è un registro da 8 bit nel quale alcuni o tutti i bit sono collegati ai pin fisici del dispositivo AVR. Tipi diversi di dispositivi AVR hanno diversi numeri di porte, che vanno da una sola sull’ATTINY13-20SQ alle nove dell’ATmega649. Le porte sono etichettate come A, B, C e così via. Ciascun pin di una porta è controllato dalla logica interna che gestisce la direzione del segnale, lo stato di una resistenza pull-up interna, il timing e altre funzioni. Potete osservarne un semplice schema nella Figura 2-3. Il Px che appare nella Figura 2-3 si riferisce al bit/pin x (da 0 a 7) della porta. Trovate una descrizione dettagliata della logica delle porte sugli AVR nella documentazione tecnica di AVR.
Figura 2-3 - Il diagramma a blocchi delle porte I/O dei dispositivi AVR.
Per via della logica sofisticata che si utilizza per controllare le funzionalità, le porte AVR possono eseguire diverse funzioni, alcune delle quali simultaneamente. Quando una porta viene configurata come output, è comunque possibile leggervi dati e un output può essere utilizzato per azionare un interrupt (come vedremo in “Gli interrupt” a pagina 26).
I timer/contatori da 8 bit Sui microcontroller AVR, sono disponibili due forme di timer/contatori da 8 bit. Nel primo tipo, l’input del clock è derivato dal clock del sistema principale e quindi il timer/contatore è sincrono. La seconda forma ha la capacità di agire in modo asincrono utilizzando una fonte di clock esterna. La Figura 2-4 mostra uno schema semplificato di un timer AVR. I registri di controllo del timer/contatore sono definiti nell’Appendice B e descritti nel dettaglio nella documentazione tecnica di Atmel.
Figura 2-4 - Il diagramma a blocchi del timer/contatore dei dispositivi AVR.
Il modulo Timer/Counter0 di una funzione periferica timer/contatore da 8 bit di un dispositivo AVR è un timer e/o contatore a scopo generale che è dotato di due circuiti di confronto degli output indipendenti con quattro modalità operative. Le modalità operative del timer/contatore sono:
Modalità normale Si tratta della modalità operativa più semplice del timer/contatore. Il conteggio si incrementa sempre e il contatore non viene azzerato quando raggiunge il suo valore massimo da 8 bit. Quando questo avviene, il contatore va in overflow e ritorna a zero. Quando il contatore torna a zero, viene impostato il Timer/Counter Overflow Flag (TOV0). Il flag TOV0 può essere visto come un nono bit, ma viene soltanto impostato, e non azzerato, dall’overflow del timer. L’interrupt dell’overflow del timer azzera automaticamente il bit del flag dell’overflow e può essere utilizzato per incrementare un secondo contatore, basato sul software, nella memoria. Un nuovo valore del contatore può essere scritto sul registro TCNT0 in qualsiasi momento.
Modalità CTC (Clear Timer on Compare) Nella modalità Clear Timer on Compare, il registro OCR0A viene utilizzato per manipolare la risoluzione del contatore definendo il suo valore massimo. Questo permette di ottenere un grande controllo della frequenza di output del compare match e aiuta a semplificare il conteggio di eventi esterni.
Modalità Fast PWM La modalità fast pulse width modulation supporta la generazione di forme d’onda PWM ad alta frequenza.
Modalità Phase correct PWM
La modalità phase correct PWM offre l’opzione di generare forme d’onda PWM ad alta risoluzione a correzione di fase. Inoltre, alcuni dispositivi AVR contengono un timer/contatore da 8 bit con la capacità di agire in modo asincrono utilizzando input di clock esterni (i pin di input del clock TOSC1 e TOSC2). Dal punto di vista funzionale è equivalente al circuito del timer/contatore sincrono da 8 bit descritto prima.
I timer/contatori da 16 bit Il timer/contatore da 16 bit è simile alla versione da 8 bit, ma con un intervallo di conteggio più esteso. È pura logica da 16 bit, che permette la generazione di PWM da 16 bit a periodo variabile. Il modulo è dotato anche di due circuiti di confronto degli output indipendenti, di registri di confronto degli output con doppio buffer e di un circuito di cattura degli input con eliminazione del disturbo. Oltre che per la generazione di PWM, il timer/contatore da 16 bit può essere utilizzato per catturare eventi esterni ad alta risoluzione, per generare frequenze e per misurare il timing dei segnali. Ha la capacità di generare quattro diversi interrupt (TOV1, OCF1A, OCF1B e ICF1).
Il prescaler del timer/contatore In un dispositivo AVR, uno o più contatori possono condividere la stessa logica del prescaler, ma con impostazioni diverse. Il prescaler è essenzialmente un circuito divisore che genera un derivato del clock I/O del sistema a f/8, f/64, f/256, oppure f/1024, che vengono detti tap. Un timer/contatore può utilizzare il tap f/64, mentre un altro può utilizzare il tap f/1024. L’utilizzo di un prescaler permettere di estendere l’intervallo di un timer/contatore in modo che si avvicini maggiormente al ritmo al quale si verifica un evento esterno e inoltre aumenta la distanza tra l’overflow e il reset del timer/contatore.
Il comparatore analogico Il comparatore analogico di un microcontroller AVR si utilizza per confrontare le tensioni di ingresso sui pin AIN0 e AIN1. Anche se AIN0 è definito come l’input positivo e AIN1 come quello negativo, questo si riferisce alla loro relazione e non alla polarità vera e propria delle tensioni di ingresso. La Figura 2-5 mostra uno schema semplificato del circuito del comparatore analogico di un AVR.
Figura 2-5 - Il diagramma a blocchi del comparatore analogico di un dispositivo AVR.
Quando AIN0 è maggiore di AIN1, la logica del comparatore imposta il flag del comparatore ACO. L’ output del comparatore può essere configurato in modo che azioni la funzione di cattura dell’input di uno dei moduli timer/contatore e può anche generare un interrupt specifico per il comparatore. L’evento interrupt può essere configurato in modo che azioni un aumento, una caduta o un cambio del comparatore. Il circuito del comparatore analogico è capace di fare ben più che semplicemente confrontare le tensioni sugli input AIN0 e AIN1. L’input del comparatore analogico può anche essere configurato in modo che l’input AIN1 possa essere confrontato con il riferimento di tensione bandgap interno, oppure AIN0 può essere confrontato con l’output del multiplexer ADC (e la sua tensione è ancora a disposizione dell’input dell’ADC). Gli insoliti simboli con le quattro frecce rappresentano porte analogiche. Come una porta risponderà a un input di controllo è indicato dal cerchio di inversione: quando si utilizza l’inversione dell’input di controllo viene passato un segnale analogico quando il controllo è low, oppure un segnale quando è high.
Il convertitore analogico-digitale Quasi tutti i microcontroller AVR contengono un convertitore analogico-digitale da 8 bit, 10 bit, oppure 12 bit. I convertitori da 8 bit si trovano sui componenti ATtiny6 e ATtiny10. Alcune delle versioni automotive del microcontroller AVR non dispongono di ADC. Quando un ADC fa parte del design dell’AVR, può essere dotato di input da 4 fino a 28. Il numero esatto degli input disponibili dipende ampiamente dalla configurazione fisica. Gli input vengono selezionati uno alla volta per mezzo di un multiplexer interno: non sono tutti attivi contemporaneamente. Inoltre, ad alcuni dei pin I/O utilizzati dal multiplexer degli input sull’ADC è anche possibile assegnare altre funzioni. I dispositivi ATmega168 sono dotati di 6-8 canali di input ADC, a seconda del package.
Il package PDIP (plastic DIP) ha un ADC da 10 bit con sei canali di input. I contenitori a montaggio superficiale TQFP e QFN/MFL hanno un ADC da 10 bit con otto canali di input. La Figura 2-6 mostra un diagramma a blocchi della funzione periferica ADC dell’AVR.
Figura 2-6 - Il diagramma a blocchi del convertitore analogico-digitale di un dispositivo AVR.
Notate che nella Figura 2-6 l’AVR utilizza quello che viene detto convertitore “ad approssimazioni successive”. Questo tipo di convertitore non è particolarmente veloce, ma è semplice da implementare, dal momento che richiede soltanto un DAC (convertitore digitale-analogico) e un comparatore. La durata tipica di una conversione sull’ADC da 10 bit di un dispositivo AVR in modalità free-running, anche se continua a mantenere la piena risoluzione, è di circa 65 microsecondi (µs) per campione.
Gli I/O seriali L’ATmega168 offre principalmente tre forme di interfaccia seriale: seriale
sincrona/asincrona, SPI master/slave sincrona e un’interfaccia a due fili orientata al byte simile allo standard I2C (Inter-Integrated Circuit) di Philips.
L’USART Un componente diffuso su molti componenti AVR è l’USART (Universal Synchronous/Asynchronous Receiver-Transmitter) integrato, detto anche UART (Universal Asynchronous Receiver-Transmitter). Questa funzione può essere usata per implementare un’interfaccia RS-232 o RS-485, oppure senza logica di interfaccia esterna per comunicazioni da chip a chip. Il baud rate viene determinato dalla frequenza del clock utilizzato sul microcontroller, ma la velocità più tipica è 9.600. Sono possibili velocità maggiori con un cristallo esterno veloce. L’USART può essere utilizzato anche nella modalità SPI (serial peripheral interface), in aggiunta alla logica dedicata alla SPI che si trova sui dispositivi AVR. La Figura 2-7 mostra i componenti interni di base della funzione periferica USART dell’AVR.
Figura 2-7 - Il diagramma a blocchi dell’USART di un dispositivo AVR.
La SPI La logica periferica SPI dell’AVR supporta tutte e quattro le modalità SPI standard di lavoro. I pin I/O del dispositivo AVR possono essere configurati in modo che si comportino come segnali MOSI, MISO e SCK1 utilizzati dalla SPI. Questi pin sono diversi dai pin RxD e TxD (receive data e transmit data) utilizzati dall’USART. La Figura 2-8 mostra una vista ad alto livello della logica della SPI.
Figura 2-8 - Il diagramma a blocchi della SPI di un dispositivo AVR.
La TWI La terza forma di I/O seriale supportato da molti dispositivi AVR è la TWI (two-wire interface). Questa interfaccia è compatibile con il protocollo I2C di Philips. Supporta sia la modalità operativa master che la slave e un indirizzo di dispositivo da 7 bit. L’interfaccia TWI può raggiungere velocità di trasferimento pari a fino 400 kHz con arbitraggio del bus multimaster e ha la capacità di generare una condizione wakeup quando il dispositivo AVR si trova in modalità sleep. Internamente, la periferica TWI è piuttosto complessa, molto più delle periferiche USART o SPI. La Figura 2-9 mostra una panoramica dell’interfaccia TWI.
Figura 2-9 - Il diagramma a blocchi della TWI (I2C) di un dispositivo AVR.
Gli interrupt Gli interrupt sono una funzione essenziale dei processori moderni. Permettono al processore di rispondere agli eventi, che siano interni o esterni, passando a un blocco speciale di codice che gestisce gli interrupt. Una volta che è stato eseguito il blocco di codice, il controllo ritorna al programma che è stato interrotto nel punto nel quale si era prodotto l’interrupt. Nei dispositivi AVR la risposta di un interrupt può essere attivata o disattivata per mezzo di bit nei registri di controllo. Questo paragrafo è specifico per l’ATmega168. Per altri tipi di microcontroller, potete consultare l’Appendice A oppure la documentazione ufficiale di Atmel (http://www.atmel.com/designsupport/documentation/). L’ATmega168 è dotato di due input di interrupt esterni: INT0 e INT1. Questi input possono essere configurati in modo che si azionino in caso di caduta, aumento o basso livello. Per configurarne il comportamento si utilizza il registro di controllo EICRA (vedere Appendice B). INT0 e INT1 richiedono la presenza di un clock I/O. La modalità low-level di un interrupt genera interrupt finché l’input rimane low. Anche i pin I/O dell’ATmega168 possono essere utilizzati come sorgenti di interrupt. Gli interrupt port-change sono definiti da PCINT0 a PCINT23 e ciascuno di essi è associato
a uno dei pin delle porte I/O del dispositivo. Quando viene attivato, un interrupt viene generato ogni volta che cambia lo stato del pin di una porta, anche se il pin è configurato in modo da comportarsi come un output. Questo permette a un pin di generare un interrupt sotto controllo del software quando un programma cambia lo stato del pin mentre l’interrupt relativo ai cambiamenti della porta è attivato. Quando un pin qualsiasi compreso tra PCINT0 e PCINT7 cambia, aziona l’interrupt PCI0. pin compresi tra PCINT8 e PCINT14 azionano PCI1 e quelli compresi tra PCINT16 e PCTIN23 azionano l’interrupt PCI2. I registri PCMSK0, PCMSK1 e PCMSK2 controllano quali pin contribuiscono agli interrupt dei cambiamenti dei pin. Quando si verifica l’attivazione di un interrupt, la CPU salta in una posizione in una tabella vettoriale della memoria, che è stata assegnata a quel particolare interrupt. L’indirizzo contiene un’istruzione jump (RJMP) che dirige al blocco di codice vero e proprio di quell’interrupt. Quando il codice dell’interrupt è terminato, l’esecuzione ritorna al punto del programma originale dove si era verificato l’interrupt. La Figura 2-10 mostra come si utilizza la tabella vettoriale degli interrupt per passare all’esecuzione del blocco di codice dell’interrupt e poi restituire il controllo al programma principale una volta terminato il codice dell’interrupt.
Figura 2-10 - I vettori degli interrupt sui dispositivi AVR (ATmega168/328).
L’ATmega168, per esempio, ha una tabella vettoriale con 26 voci, come mostra la Tabella 2-1. Per altri tipi di processori, potete consultare la documentazione di Atmel, dove trovate ulteriori informazioni sugli interrupt e su come vengono gestiti sui dispositivi AVR. Tabella 2-1 - I vettori degli interrupt sull’ATmega168.
Vettore
Indirizzo
Sorgente
Definizione
Pin esterno, accensione, calo di tensione e watchdog
1
0x0000
RESET
2
0x0002
INT0
Richiesta 0 di interrupt esterno
3
0x0004
INT1
Richiesta 1 di interrupt esterno
4
0x0006
PCINT0
Richiesta 0 di interrupt cambio di pin
5
0x0008
PCINT1
Richiesta 1 di interrupt cambio di pin
6
0x000A
PCINT2
Richiesta 2 di interrupt cambio di pin
7
0x000C
WDT
8
0x000E
TIMER2
COMPA Confronto corrispondenza Timer/Counter2 A
9
0x0010
TIMER2
COMPB Confronto corrispondenza Timer/Counter2 B
10
0x0012
TIMER2
OVF overflow Timer/Counter2
11
0x0014
TIMER1
CAPT Cattura di eventi Timer/Counter1
12
0x0016
TIMER1
COMPA Confronto corrispondenza Timer/Counter1 A
13
0x0018
TIMER1
COMPB Confronto corrispondenza Timer/Counter1 B
14
0x001A
TIMER1
OVF Overflow Timer/Counter1
15
0x001C
TIMER0
COMPA Timer/Counter0 corrispondenza A
16
0x001E
TIMER0
COMPB Timer/Counter0 corrispondenza B
17
0x0020
TIMER0
OVF Overflow Timer/Counter1
18
0x0022
SPI, STC
SPI Trasferimento seriale completato
19
0x0024
USART, RX
USART, Rx completo
20
0x0026
USART, UDRE
USART, registro dati vuoto
21
0x0028
USART, TX
USART, Tx completo
22
0x002A
ADC
23
0x002C
EE READY
24
0x002E
ANALOG COMP
Interrupt watchdog di time-out
Conversione ADC completata EEPROM pronta Comparatore analogico
25
0x0030
TWI
26
0x0032
SPM READY
Interfaccia a due fili seriale Programma di memorizzazione pronto
Il timer watchdog L’AVR mette a disposizione un timer watchgod (WDT, watchdog timer) con un periodo di time-out che si può configurare tra 16 e 8 ms. Se il WDT è attivato, può essere utilizzato per generare un reset subito dopo un time-out, generare un interrupt al verificarsi di un time-out, oppure una combinazione di entrambi. Utilizza un oscillatore sul chip separato e, dato che il WDT è gestito da un oscillatore separato, continua a contare anche quando il microcontroller si trova nella modalità sleep. Per questo può essere utilizzato per svegliare il microcontroller dopo un determinato periodo di tempo. Un altro utilizzo comune del WDT è per forzare un reset oppure un interrupt se il timer scade senza un’azione di reset da parte del software. Questo si rivela utile per obbligare il microcontroller a uscire da uno stato di stallo oppure per rilevare un codice fuori controllo.
Caratteristiche elettriche I microcontroller AVR ATmega168 e ATmega328 possono funzionare con una tensione di alimentazione da 1,8 a 5,5 V DC. L’ATmega32U4 può utilizzare una tensione di alimentazione da 2,7 a 5,5 V DC. Il consumo di corrente di un dispositivo AVR varia a seconda del tipo di dispositivo, dello stato attivo o disattivo (sleep) del microcontroller e della velocità del clock. I valori delle linee di prodotti ATmega e XMEGA oscillano tra 0,55 mA ai 30 mA. Il consumo di corrente complessivo dipende anche dalla quantità di corrente che scorre attraverso i pin I/O. Il Capitolo 3 elenca i valori specifici relativi ai microcontroller ATmega168, ATmega328, ATmega1280, ATmega2560 e ATmega32U4.
Per ulteriori informazioni Il Capitolo 3 descrive i pinout utilizzati sui tre tipi di MCU AVR che si trovano sulle schede Arduino, mentre il Capitolo 4 mostra come i pin delle MCU AVR sono mappati sui pin I/O delle varie schede Arduino. Ciascuna delle varie MCU AVR possono avere diverse combinazioni di funzioni periferiche interne e, in alcuni casi, la funzionalità può variare leggermente a seconda del tipo. La fonte migliore di informazioni relative alle MCU AVR è il sito web di Atmel
(http://www.atmel.com).
3 I microcontroller AVR specifici per Arduino
Questo capitolo presenta le descrizioni tecniche dei tipi di componenti AVR che si utilizzano nei modelli di Arduino basati sui dispositivi AVR da 8 bit. Il suo scopo è rappresentare la continuazione delle descrizioni funzionali presentate nel Capitolo 2 rispetto ai microcontroller AVR in generale, ma prestando particolare attenzione ai microcontroller ATmega168/328, ATmega1280/2560 e ATmega32U4. Dal punto di vista di qualcuno che programmi un Arduino con l’IDE, il microcontroller è un’astrazione semplificata del dispositivo AVR vero e proprio che vi si nasconde. Il codice necessario per eseguire operazioni come configurare un pin di output per generare un segnale PWM oppure dirigere internamente una tensione analogica nell’ADC integrato è semplice. Gli indirizzi interni dei registri di controllo e i loro bit di controllo sono predefiniti, in modo che l’autore dello sketch non debba preoccuparsi dei dettagli di basso livello. Dal momento che una scheda Arduino in realtà non è niente più che il package di un chip AVR, le caratteristiche elettriche di Arduino sono per lo più quelle del processore. I pin del chip sono collegati direttamente ai terminali dei pin o alle flange di saldatura sul bordo della scheda Arduino. Tra i punti di connessione del chip e della scheda non c’è né buffer né level-shifting (traslatori di livello). Quando stavo scrivendo questo libro, Arduino utilizzava cinque tipi fondamentali di microcontroller ATmega e tre variazioni, per un totale di otto componenti, che trovate elencati nella Tabella 3-1. Le differenze principali tra i vari dispositivi AVR risiede nella quantità memoria flash integrata a disposizione, nella velocità massima del clock, nel numero di pin I/O sul chip e naturalmente nelle funzioni periferiche interne disponibili. Il dispositivo ATmega32U4 dispone anche di un’interfaccia USB integrata, che elimina la necessità di un secondo componente per gestire le comunicazioni USB. Tutti i dispositivi utilizzano la stessa serie di istruzioni delle CPU. Tabella 3-1 - I microcontroller AVR utilizzati nei prodotti Arduino.
Microcontroller
Flash
Pin I/O (max)
Note
ATmega168
16K
23
clock 20 MHz
ATmega168V
16K
23
clock 10 MHz
ATmega328
32K
23
clock 20 MHz
ATmega328P
32K
23
clock 20 MHz, picoPower
ATmega328V
32K
23
clock 10 MHz
ATmega1280
128K
86
clock 16 MHz
ATmega2560
256K
86
clock 16 MHz
ATmega32U4
32K
26
clock 16 MHz
Questo livello intrinseco di compatibilità fa sì che i programmi scritti per un Arduino Diecimila possano essere compilati ed eseguiti senza modifica su una Uno. La differenza principale tra una scheda Diecimila e una Uno è che una utilizza l’ATmega168 e l’altra si basa sull’ATmega328P. Come potete osservare nella Tabella 3-1, l’ATmega328P ha il doppio di memoria flash integrata rispetto all’ATmega168. Pertanto, i programmi scritti per una scheda Uno possono non essere retrocompatibili con una Diecimila, se il codice è stato progettato per essere utilizzato con una quantità di memoria superiore.
L’ATmega168/328 L’ATmega168 e l’ATmega328 sono fondamentalmente lo stesso con quantità diverse di memoria integrata. Nella Figura 3-1 è mostrato il diagramma a blocchi di un dispositivo ATmega168 o 328.
Figura 3-1 - Il diagramma a blocchi del microcontroller ATmega168/328.
La memoria L’ATmega328 ha una quantità di memoria di ogni tipo doppia rispetto all’ATmega168, come mostra la Tabella 3-2. A parte questo, i due componenti sono identici. Tabella 3-2 - La memoria integrata dell’ATmega168/328.
Memoria programma flash EEPROM RAM
ATmega168
ATmega328
16 KB
32 KB
512 byte
1 KB
1 KB
2 KB
Le caratteristiche Questi due componenti hanno in comune queste caratteristiche: •
Programmazione in-system che utilizza il programma di avvio presente sul chip
•
Due timer/contatori da 8 bit con prescaler separato e modalità di confronto
•
Un timer/contatore da 16 bit con prescaler separato, modalità di confronto e
modalità di cattura •
Contatore in tempo reale con oscillatore separato
•
Sei canali PWM
•
ADC da 10 bit a sei o otto canali (a seconda del package)
•
USART
•
Interfaccia seriale SPI master/slave
•
Interfaccia seriale a due fili (compatibile con I2C di Philips)
•
Timer watchdog programmabile
•
Comparatore analogico
•
23 linee I/O programmabili
I package (contenitori) L’ATmega168 e l’ATmega384 sono disponibili in quattro tipi diversi di package: DIP da 28 pin, MLF a montaggio superficiale da 28 pin, TQFP a montaggio superficiale da 32 pin e MLF a montaggio superficiale da 32 pin. Il DIP da 28 pin è il package utilizzato più comunemente sulle schede Arduino, anche se la Uno SMD utilizza un contenitore a montaggio superficiale da 32 pin. Questo paragrafo è dedicato alla versione PDIP dell’ATmega168.
Le porte L’ATmega168/328 è dotato di tre porte designate come B, C e D. Le porte B e D sono porte da 8 bit. La porta C ha a sua disposizione sei pin che possono essere utilizzati come input ADC. Inoltre, PC4 e PC5 sono collegati alla logica della TWI e offrono segnali SCL e SDA compatibili con I2C (clock e dati). Notate anche che di solito PC6 viene utilizzato come input per il RESET. Sui componenti non c’è PC7. E notate ancora che sul componente ATmega168/328 non c’è Porta A. Ciascuna porta offre I/O digitali bidirezionali e discreti con resistenze pull-up programmabili interne. Gli stati on/off delle resistenze pull-up si selezionano per mezzo dei bit dei registri di controllo dei pin specifici delle porte. I buffer di output delle porte hanno funzionalità di trasmissione simmetriche con capacità sink e source. Come input, i pin delle porte che sono resi esternamente low forniscono corrente se le resistenze pull-up interne sono attivate. I pin delle porte sono passati in una modalità a tre stati (alta impedenza) quando diventa attiva una condizione di reset, anche se il clock non è attivo.
Le funzioni dei pin La Figura 3-2 mostra le funzioni dei pin del package DIP da 28 pin. Per maggiori
informazioni sui pinout dei contenitori a montaggio superficiale potete consultare la documentazione di Atmel (http://bit.ly/atmel-docs).
Figura 3-2 - Le funzioni dei pin del package DIP del microcontroller ATmega168/328.
Gli input del comparatore analogico La Figura 3-3 mostra le posizioni dei pin AIN0 e AIN1 sull’ATmega168 o sull’ATmega328 in un package PDIP. Notate che AIN0 condivide un pin con l’output del timer/contatore OC0A (PD6). Quindi, se PD6 viene utilizzato come output PWM, non può essere utilizzato come input AIN0 a meno che non venga riconfigurato ogni volta che deve cambiare la sua funzione.
Figura 3-3 - I pin di input del comparatore analogico sul microcontroller ATmega168/328.
Gli input analogici A eccezione che per i pin SCL e SDA che si utilizzano per le comunicazioni seriali della TWI, i pin dell’input analogico possono essere utilizzati come I/O digitali discreti oppure come input analogici senza conflitti con altre funzioni periferiche dell’AVR. La Figura 3-4 mostra i pin del package PDIP di un ATmega168 utilizzati per gli input analogici.
Figura 3-4 - I pin di input ADC del microcontroller ATmega168/328.
Le interfacce seriali La Figura 3-5 mostra i pin I/O di un ATmega168 (package PDIP) utilizzati dalle funzioni dell’interfaccia seriale. Dal momento che nessuna delle funzioni seriali condivide i pin delle porte, è possibile utilizzarne tutte e tre le forme senza conflitti sulle porte.
Figura 3-5 - I pin I/O seriali del microcontroller ATmega168/328.
Gli I/O del timer/clock La logica del timer/contatore interno di un AVR ATmega168/328 è complessa e questo è dimostrato dall’assegnazione dei pin del chip, mostrata nella Figura 3-6. Notate che i pin OCxn (OC0A, OC0B, OC1A, OC1B, OC2A e OC2B) sono disponibili come output PWM e così è come appaiono etichettati sulle schede Arduino. Notate anche che T1 e OSC0B condividono lo stesso pin (PD5), ma altrimenti gli output compatibili con PWM possono essere utilizzati senza conflitti con altre funzioni del timer/contatore.
Figura 3-6 - I pin del timer/contatore del microcontroller ATmega168/328.
Gli interrupt esterni I pin PD2 e PD3 della porta D sono pensati espressamente per essere utilizzati come input per gli interrupt esterni. Anche qualunque pin compreso tra i pin PCINT0 e PCINT23 può essere utilizzato come input per gli interrupt esterni senza interferire con altre funzioni assegnate (per una panoramica di come possono essere utilizzati questi interrupt, vedere “Gli interrupt” a pagina 26). La Figura 3-7 mostra gli input per gli interrupt esterni disponibili sui dispositivi ATmega168/328.
Figura 3-7 - I pin degli input per gli interrupt sui microcontroller ATmega168/328.
Le assegnazioni dei pin di Arduino Le schede Diecimila, Duemilanove, Uno ed Ethernet utilizzano fondamentalmente lo stesso layout della scheda (descritto nel Capitolo 4), come mostra la Figura 3-8. Per i pin socket header, queste schede Arduino utilizzano una nomenclatura basata sulle funzioni dei pin dell’ATmega168 o dell’ATmega328 installati sulla PCB. L’enfasi è posta soprattutto sulle funzioni che si utilizzano più spesso, cioè gli I/O digitali discreti, gli input analogici e le funzioni di output PWM dei microcontroller AVR.
Figura 3-8 - Le etichette dei pin Arduino sull’ATmega168/328.
Le caratteristiche elettriche fondamentali La Tabella 3-3 mostra alcune delle caratteristiche elettriche fondamentali dei microcontroller ATmega168/328, sottolineandone il consumo energetico. Tabella 3-3 - Il consumo energetico dell’ATmega168/328.
Dispositivo
Parametro Corrente di alimentazione
ATmega168
Modalità risparmio energetico
Condizione
VCC
Tipico
Max
Attivo 8 MHz
5 V
4,2 mA
12 mA
Inattivo 8 MHz
5 V
0,9 mA
5,5 mA
32 MHz TOSC
1,8 V
0,75 uA
32 MHz TOSC
5 V
0,83 uA
Modalità spegnimento
Corrente di alimentazione ATmega328
Modalità risparmio energetico Modalità spegnimento
WDT attivato
3 V
4,1 uA
15 uA
WDT disattivato
3 V
0,1 uA
2 uA
Attivo 8 MHz
5 V
5,2 mA
12 mA
Inattivo 8 MHz
5 V
1,2 mA
5,5 mA
32 MHz TOSC
1,8 V
0,8 uA
32 MHz TOSC
5 V
0,9 uA
WDT attivato
3 V
4,2 uA
15 uA
WDT disattivato
3 V
0,1 uA
2 uA
Con un VCC compreso tra 1,8 e 2,4 volt, un input low su un I/O è definito come tensione compresa tra –0,5 e due decimi (0,2) di VCC. Per un VCC compreso tra 2,4 e 5,5 volt, un input low su un I/O è definito come tensione compresa tra –0,5 e tre decimi (0,3) di VCC. Con un VCC compreso tra 1,8 e 2,4 volt, un input high è definito come tensione compresa tra sette decimi (0,7) VCC e VCC + 0,5 volt. Per un VCC compreso tra 2,4 e 5,5 volt, è definito come tensione compresa tra sei decimi (0,6) VCC e VCC + 0,5 volt.
L’ATmega1280/ATmega2560 Come nel caso dell’ATmega168/328, la differenza principale tra l’ATmega1280 e l’ATmega2560 è la quantità di memoria integrata. Per quanto riguarda tutto il resto, questi dispositivi sono identici. Nella Figura 3-9 è mostrato un diagramma a blocchi semplificato di un dispositivo ATmega1280 o 2560.
Figura 3-9 - Il diagramma a blocchi dell’interno dei microcontroller ATmega1280/2560.
Se vogliamo essere più precisi, nella Figura 3-9 mancano alcuni piccoli dettagli, ma appaiono tutti i componenti essenziali. Se desiderate osservare un diagramma più dettagliato, potete cercarlo nella documentazione di Atmel relativa ai componenti ATmega1280 e ATmega2560. Notate anche che la Figura 3-9 mostra le funzioni interne disponibili sul package da 100 pin. Quello da 64 pin supporta un sottogruppo di quello che è descritto qui.
La memoria L’ATmega2560 è dotato del doppio di ciascun tipo di memoria rispetto all’ATmega1280 e di otto volte più memoria flash rispetto all’MCU dell’ATmega328. La memoria disponibile è mostrata nella Tabella 3-4. A parte questo, l’ATmega1280 e l’ATmega2560 con gli stessi tipi di package sono identici. Tabella 3-4 - La memoria integrata dell’ATmega1280/2560.
ATmega1280
ATmega2560
128 KB
256 KB
EEPROM
4 KB
4 KB
RAM
8 KB
8 KB
Memoria programma flash
Le caratteristiche Questi due componenti condividono queste caratteristiche: •
Programmazione in-system che utilizza il programma di avvio presente sul chip
•
Due timer/contatori da 8 bit con prescaler separato e modalità di confronto
•
Quattro timer/contatori da 16 bit con prescaler separato, modalità di confronto e modalità di cattura
•
Contatore in tempo reale con oscillatore separato
•
12 Canali Pwm
•
Uscita del modulatore comparatore
•
ADC da 10 bit e sei canali
•
Quattro funzioni USART
•
Interfaccia seriale SPI master/slave
•
Interfaccia seriale a due fili (compatibile con I2C di Philips)
•
Timer watchdog programmabile
•
Comparatore analogico
•
86 linee I/O programmabili
I package I dispositivi ATmega1280 e ATmega2560 si trovano in un package TQFP da 100 pin, un package BGA (ball grid array) da 100 pin e un package TQFP da 64 pin. La Figura 3-10 mostra le dimensioni relative e lo spazio tra i pin (pitch) dei tre tipi di package disponibili. Soltanto i package da 100 pin offrono tutte le funzionalità mostrate nella Figura 3-9. Le schede Arduino Mega e Mega2560 utilizzano entrambe la versione da 100 pin del package TQFP.
Figura 3-10 - I package dell’ATmega1280/2560.
Le porte Le versioni da 100 pin dell’ATmega1280 e dell’ATmega2560 sono dotate di 11 porte, etichettate da A a L. Notate che la porta I non c’è, dal momento che la lettera I potrebbe essere confusa con il numerale 1. Le porte A, B, C, D ed E sono porte da 8 bit bidirezionali. La porta B ha capacità di trasmissione migliori delle altre porte. Le porte F e K si utilizzano come input del convertitore A/D interno, ma possono fungere anche da porte bidirezionali. La porta G è una porta da 6 bit e le porte H, J e L sono interfacce bidirezionali da 8 bit. Ciascuna porta mette a disposizione I/O digitali discreti con resistenze pull-up interne programmabili. Gli stati on/off delle resistenze pull-up si selezionano per mezzo dei bit del registro di controllo dei pin della porta. I buffer di output delle porte hanno funzionalità di trasmissione simmetriche con capacità sink e source. Come input, i pin delle porte che sono resi esternamente low forniscono corrente se le resistenze pull-up interne sono attivate. I pin delle porte sono passati in una modalità a tre stati (alta impedenza) quando diventa attiva una condizione di reset.
Le funzioni dei pin I diagrammi mostrati in questo paragrafo si riferiscono alla versione da 100 pin dei dispositivi ATmega1280/2560. Per ulteriori dettagli sui componenti BGA e da 64 pin, potete consultare la documentazione tecnica di Atmel.
Gli input del comparatore analogico Come i dispositivi ATmega168/328, più piccoli, i componenti ATmega1280/2560 sono dotati di due input del comparatore analogico, come indicato nel dettaglio nella Tabella
3-5 e mostrato nella Figura 3-11. Tabella 3-5 - Gli input del comparatore analogico.
Pin
Porta
Funzione
4
PE2
AIN0
5
PE3
AIN1
Figura 3-11 - I pin degli input del comparatore analogico dell’ATmega1280/2560.
Gli input analogici I dispositivi ATmega1280/2560 supportano fino a 16 input del convertitore A/D. Questi si trovano sulle porte F e K e sul package da 100 pin sono collegati ai pin dal 82 a 97 (vedere Tabella 3-6). Tabella 3-6 - Gli input analogici.
Pin
Porta
Funzione
Pin
Porta
Funzione
82
PK7
ADC15
90
PF7
ADC7
83
PK6
ADC14
91
PF6
ADC6
84
PK5
ADC13
92
PF5
ADC5
85
PK4
ADC12
93
PF4
ADC4
86
PK3
ADC11
94
PF3
ADC3
87
PK2
ADC10
95
PF2
ADC2
88
PK1
ADC9
96
PF1
ADC1
89
PK0
ADC8
97
PF0
ADC0
Anche la porta F ha funzioni alternate TCK, TMS, TDI e TDO e i pin della porta K sono collegati agli interrupt da PCINT16 a PCINT23. Le posizioni fisiche dei pin sono mostrate nella Figura 3-12.
Figura 3-12 - I pin degli input ADC dell’ATmega1280/2560.
Le interfacce seriali I dispositivi ATmega1280/2560 sono dotati di quattro funzioni USART interne. Queste si presentano nella forma di quattro coppie di pin, delle quali una funge da TXD e l’altra da RXD. Sui package da 100 pin, l’interfaccia SPI è disponibile sulla porta B sui pin dal 19 al 22. L’interfaccia a due fili (I2C) è collegata alla porta D per mezzo dei pin dal 43 al 44. Le assegnazioni dei pin sono elencati nelle Tabelle dalla 3-7 alla 3-12. La Figura 313 mostra le posizioni dei pin I/O seriali sul package da 100 pin. Tabella 3-7 - USART 0.
Pin
Porta
Funzione
2
PE0
RXD0
3
PE1
TXD0
Tabella 3-8 - USART 1.
Pin
Porta
Funzione
45
PD2
RXD1
46
PD3
TXD1
Tabella 3-9 - USART 2.
Pin
Porta
Funzione
12
PH0
RXD2
13
PH1
TXD2
Tabella 3-10 - USART 4.
Pin
Porta
Funzione
63
PJ0
RXD3
64
PJ1
TXD3
Tabella 3-11 - SPI.
Pin
Porta
Funzione
19
PB0
SS (active low)
20
PB1
SCK
21
PB2
MOSI
22
PB3
MISO
Tabella 3-12 - TWI.
Pin
Porta
Funzione
43
PD0
SCL
44
PD1
SDA
Figura 3-13 - I pin I/O seriali dell’ATmega1280/2560.
Gli I/O del timer/clock Nel dispositivo ATmega1280/2560 ci sono cinque funzioni timer/contatore, come mostra la Figura 3-14.
Figura 3-14 - I pin del timer/contatore sull’ATmega1280/2560.
La Tabella 3-13 ne elenca i pin. Notate che non c’e il pin T2. Tabella 3-13 - I pin del timer/contatore dell’Atmega1280/2560.
Pin
Porta
Funzione
Pin
Porta
Funzione
1
PG5
OC0B
50
PD7
T0
5
PE3
OC3A
15
PH3
OC4A
6
PE4
OC3B
16
PH4
OC4B
7
PE5
OC3C
17
PH5
OC4C
8
PE6
T3
18
PH6
OC2B
9
PE7
ICP3
27
PH7
T4
23
PB4
OC2A
35
PL0
ICP4
24
PB5
OC1A
36
PL1
ICP5
25
PB6
OC1B
37
PL2
T5
26
PB7
OC0A/OC1C
38
PL3
OC5A
47
PD4
ICP1
39
PL4
OC5B
49
PD6
T1
40
PL5
OC5C
Gli interrupt esterni I dispositivi ATmega1280/2560 supportano otto input per gli interrupt esterni, oltre alle funzioni di interrupt disponibili sulle porte B, J e K. I pin sono elencati nella Tabella 3-14. Tabella 3-14 - I pin degli interrupt sull’ATmega 1280/2560.
Pin
Porta
Funzione
Pin
Porta
Funzione
6
PE4
INT4
43
PD0
INT0
7
PE5
INT5
44
PD1
INT1
8
PE6
INT6
45
PD2
INT2
9
PE7
INT7
46
PD3
INT3
Le assegnazioni dei pin di Arduino Le schede Arduino Mega e Mega2560 utilizzano il layout della scheda descritto nel Capitolo 4. Per quanto riguarda i pin socket header, queste schede Arduino utilizzano una nomenclatura basata sulle funzioni dei pin dell’ATmega1280 o dell’ATmega2650 installati sulla PCB. L’enfasi è posta soprattutto sulle funzioni che si utilizzano più spesso, cioè gli I/O digitali discreti, gli input analogici e le funzioni di output PWM dei
microcontroller AVR. La Tabella 3-15 elenca i pin della Mega o Mega2560 e le connessioni al dispositivo AVR ATmega1280/2560 sulla scheda. Le funzioni racchiuse tra parentesi sono i pin di indirizzamento della memoria esterna e la tilde (~) serve a indicare un segnale activelow (true quando low). A differenza delle schede Arduino più piccole, le schede Mega sono in grado di utilizzare SRAM esterna. Tabella 3-15 - Le assegnazioni dei pin su Arduino Mega e Mega2560.
Pin sulla scheda Mega
N° pin sul chip
Funzione
Pin sulla scheda Mega
N° pin sul chip
Funzione
0
2
RXD0
35
55
I/O (A10)
1
3
TXD0
36
54
I/O (A9)
2
5
OC3B [PWM]
37
53
I/O (A8)
3
6
OC3C [PWM]
38
50
T0
4
1
OC0B [PWM]
39
70
I/O (ALE)
5
4
OC3A [PWM]
40
52
I/O (~RD)
6
15
OC4A [PWM]
41
51
I/O (~WR)
7
16
OC4B [PWM]
42
42
PL7
8
17
OC4C [PWM]
43
41
PL6
9
18
OC2B [PWM]
44
40
OC5C [PWM]
10
23
OC2A [PWM]
45
39
OC5B [PWM]
11
24
OC1A [PWM]
46
38
OC5A [PWM]
12
25
OC1B [PWM]
47
37
T5
13
26
OC0A [PWM]
48
36
ICP5
14
64
TXD3
49
35
ICP4
15
63
RXD3
50
22
MISO
16
13
TXD2
51
21
MOSI
17
12
RXD2
52
20
SCK
18
46
TXD1
53
19
~SS
19
45
RXD1
54
97
A0 (ingresso analogico)
20
44
SDA
55
96
A1 (ingresso analogico)
21
43
SCL
56
95
A2 (ingresso analogico)
22
78
I/O (AD0)
57
94
A3 (ingresso analogico)
23
77
I/O (AD1)
58
93
A4 (ingresso analogico)
24
76
I/O (AD2)
59
92
A5 (ingresso analogico)
25
75
I/O (AD3)
60
91
A6 (ingresso analogico)
26
74
I/O (AD4)
61
90
A7 (ingresso analogico)
27
73
I/O (AD5)
62
89
A8 (ingresso analogico)
28
72
I/O (AD6)
63
88
A9 (ingresso analogico)
87
A10 (ingresso analogico)
86
A11 (ingresso analogico)
85
A12 (ingresso analogico)
84
A13 (ingresso analogico)
29
30
31
32
71
60
59
58
I/O (AD7)
I/O (A15)
I/O (A14)
I/O (A13)
64
65
66
67
33
34
57
56
I/O (A12)
68
I/O (A11)
69
83
82
A14 (ingresso analogico) A15 (ingresso analogico)
Figura 3-15 - I pin degli input degli interrupt sull’ATmega1280/2560.
Notate che i pin dal 22 al 37 e i pin 39, 40 e 41 possono essere utilizzati per accedere alla memoria esterna. Altrimenti, possono essere utilizzati come singoli pin I/O digitali.
Le caratteristiche elettriche La Tabella 3-16 mostra alcune delle caratteristiche elettriche fondamentali dei microcontroller ATmega1280/2560, sottolineandone il consumo energetico. Tabella 3-16 - Il consumo energetico dell’ATmega1280/2560.
Dispositivo
Parametro
Condizione
VCC
Tipico
Max
ATmega1280
Corrente di alimentazione
Attivo 8 MHz
5 V
10 mA
14 mA
ATmega2560
Corrente di alimentazione
Inattivo 8 MHz
5 V
2,7 mA
4 mA
WDT attivato
15 uA
entrambi
Modalità risparmio energetico
WDT disattivato
3 V 3 V
<5 uA <1 uA
7,5 uA
Con un VCC compreso tra 1,8 e 2,4 volt, un input low su un pin I/O è definito come tensione compresa tra –0,5 e due decimi (0,2) di VCC. Per un VCC compreso tra 2,4 e 5,5 volt, un input low è definito come tensione compresa tra –0,5 e tre decimi (0,3) di VCC. Con un VCC compreso tra 1,8 e 2,4 volt, un input high è definito come tensione compresa tra sette decimi (0,7) VCC e VCC + 0,5 volt. Per un VCC compreso tra 2,4 e 5,5 volt, è definito come tensione compresa tra sei decimi (0,6) VCC e VCC + 0,5 volt.
L’ATmega32U4 L’ATmega32U4 è un membro della linea di microcontroller XMEGA di Atmel. È dotato di 32 KB di memoria programma flash, 2,5 KB di SRAM e 1 KB di EEPROM. Alle funzioni I/O si accede per mezzo delle porte dalla B alla F. In questo specifico dispositivo, non c’è porta A. La Figura 3-16 mostra il diagramma a blocchi dei principali componenti interni dell’ATmega32U4.
Figura 3-16 - Il diagramma a blocchi del funzionamento interno del microcontroller ATmega32U4.
L’ATmega32U4 presenta un’interfaccia USB 2.0 veloce e integrata, che elimina la necessità di un’interfaccia separata. Include inoltre un’interfaccia JTAG conforme 1149.1 per il debugging sul chip. L’ATmega32U4 può funzionare con una tensione compresa tra 2,7 e 5,5 volt.
La memoria Come mostra la Tabella 3-17, l’ATmega32U4 ha la stessa quantità di memoria flash e di EEPROM dell’ATmega328, ma è dotato di 2,5 KB di RAM anziché di 2 KB. Tabella 3-17 - La memoria integrata dell’ATmega32U4.
ATmega32U4 Memoria programma flash
32 KB
EEPROM
1 KB
RAM
2,5 KB
Le caratteristiche L’ATmega32U4 presenta queste caratteristiche: •
Programmazione in-system che utilizza il programma di avvio presente sul chip
•
Un timer/contatore da 8 bit con prescaler separato e modalità di confronto
•
Due timer/contatori da 16 bit con prescaler separato, modalità di confronto e modalità di cattura
•
Un timer/contatore da 10 bit ad alta velocità con PLL (phase-locked loop) e modalità di confronto
•
Quattro canali PWM da 8 bit
•
Quattro canali PWM con risoluzione programmabile da 2 a 16 bit
•
Sei canali PWM ad alta velocità con risoluzione programmabile da 2 a 11 bit
•
Uscita del modulatore comparatore
•
ADC da 10 bit e 12 canali
•
Funzioni USART con handshake CTS/RTS
•
Interfaccia seriale SPI master/slave
•
Interfaccia seriale a due fili (compatibile con I2C di Philips)
•
Timer watchdog programmabile
•
Comparatore analogico
•
Sensore di temperatura integrato
•
26 linee I/O programmabili
I package L’ATmega32U4 è disponibile nei contenitori a montaggio superficiale TQFP44 o QFN44. Le designazioni dei pin, mostrata nella Figura 3-17, sono le stesse per entrambi i tipi di package.
Figura 3-17 - Il package da 44 pin del microcontroller ATmega32U4.
Le porte L’ATmega32U4 ha cinque porte etichettate da B a F. Nei contenitori a montaggio superficiale QFN/TQFP da 44 pin soltanto le porte B e D hanno tutti gli otto bit presenti sui pin del package. Le porte C, E ed F sono rappresentate internamente come registri da 8 bit, ma soltanto i bit PC6 e PC7 della porta C sono disponibili esternamente. Nel caso della porta E, soltanto i bit PE2 e PE6 sono disponibili esternamente e in quello della porta F i bit PF2 e PF3 non sono presenti sui pin del package. Oltre alle varie funzioni periferiche, le porte B, C, D, E ed F sono porte I/P digitali, bidirezionali e discrete. Ciascuna porta fornisce I/O digitali, bidirezionali e discreti con resistenze pull-up interne programmabili. Gli stati on/off delle resistenze pull-up si selezionano per mezzo dei bit del registro di controllo dei pin delle porte. I buffer di output delle porte hanno funzionalità di trasmissione simmetriche con capacità sink e source. Come input, i pin delle porte che sono resi esternamente low forniscono corrente se le resistenze pull-up interne sono attivate. I pin delle porte sono passati in una modalità a tre stati (alta impedenza) quando diventa attiva una condizione di reset.
Le funzioni dei pin La Tabella 3-18 elenca le assegnazioni dei pin dell’ATmega32U4 in un package da 44
pin. La mappatura dei pin del chip rispetto i pin degli header della scheda Arduino Leonardo si trova in “Le assegnazioni dei pin di Arduino” a pagina 61. Tabella 3-18 - Le assegnazioni dei pin sull’ATmega32U4 TQFP/QFN-44.
Pin
Funzioni
Porta
Pin
Funzioni
Porta
1
INT6/AIN0
PE6
16
XTAL2
n/d
2
USB UVCC
n/d
17
XTAL1
n/d
3
USB D–
n/d
18
OC0B/SCL/INT0
PD0
4
USB D+
n/d
19
SDA/INT1
PD1
5
USB UGnd
n/d
20
RXD1/INT2
PD2
6
USB UCap
n/d
21
TXD1/INT3
PD3
7
USB VBus
n/d
22
XCK1/CTS
PD5
8
PCINT0/SS
PB0
23
GND
n/d
9
PCINT1/SCLK
PB1
24
AVCC
n/d
10
PDI/PCINT2/MOSI
PB2
25
ICP1/ADC8
PD4
11
PDO/PCINT3/MISO
PB3
26
T1/OC4D/ADC9
PD6
12
PCINT7/OC0A/OC1C/RTS
PB7
27
T0/OC4D/ADC10
PD7
13
RESET
n/d
28
PCINT4/ADC11
PB4
14
VCC
n/d
29
PCINT5/OC1A/OC4B/ADC12
PB5
Gli input del comparatore analogico Sull’ATmega32U4 c’è soltanto un input esterno per il comparatore analogico. AIN0 si trova sul pin 1. L’altro input del comparatore analogico va dal multiplexer di input all’ADC integrato sul chip. Il circuito interno è identico a quello mostrato in “Il comparatore analogico” a pagina 21 ma senza il collegamento del pin AIN1.
Gli input analogici L’ATmega32U4 mette a disposizione 12 input del convertitore A/D, elencati nella Tabella 3-19 e mostrati nella Figura 3-18. Questi si trovano sulle porte B, D ed F. Notate che ADC2 e ADC3 non hanno pin esterni. Tabella 3-19 - Gli input ADC dell’ATmega32U4.
Pin
Porta
Funzione
Pin
Porta
Funzione
Pin
Porta
Funzione
41
PF0
ADC0
37
PF6
ADC6
27
PD7
ADC10
40
PF1
ADC1
36
PF7
ADC7
28
PB4
ADC11
39
PF4
ADC4
25
PD4
ADC8
29
PB5
ADC12
38
PF5
ADC5
26
PD6
ADC9
30
PB6
ADC13
Figura 3-18 - I pin di input ADC dell’ATmega132U4.
Le interfacce seriali L’ATmega32U4 ha una funzione USART interne con linee di handshake hardware, un’interfaccia SPI e un’interfaccia a due fili (TWI) compatibile I2C (vedere le Tabelle dalla 3-20 alla 3-22). L’interfaccia USB viene descritta più avanti, nella Figura 3-22. Le assegnazioni dei pin sono mostrate nella Figura 3-19. Tabella 3-20 - USART.
Pin
Porta
Funzione
Pin
Porta
Funzione
20
PD2
RXD1
22
PD5
CTS
21
PD3
TXD1
12
PB7
RTS
Tabella 3-21 - SPI.
Pin
Porta
Funzione
Pin
Porta
Funzione
8
PB0
SS
10
PB2
MOSI
9
PB1
SCLK
11
PB3
MISO
Tabella 3-22 - TWI.
Pin
Porta
Funzione
18
PD0
SCL
19
PD1
SDA
Figura 3-19 - I pin I/P seriali dell’ATmega32U4.
Gli I/O del timer/clock L’ATmega32U4 è dotato di quattro funzioni timer/contatore integrate sul chip. Queste consistono di un timer/contatore da 8 bit integrato, due timer/contatori da 16 bit con prescaler e modalità di confronto separati e un timer/contatore da 10 bit ad alta velocità con PLL (phase-locked loop) e una modalità di confronto. Notate che i timer/contatori da 16 bit supportano anche una modalità di cattura.
I timer sono numerati da 0 a 4, ma non esiste il timer/contatore 2. I pin OC1A, OC1B e T0 del timer/contatore 0 agiscono su pin condivisi con il timer/contatore 4 (il timer/contatore ad alta velocità). Analogamente, i pin dei timer/contatori 1 e 3 sono condivisi con pin disponibili per il timer/contatore 4. La Tabella 3-23 elenca le assegnazioni dei pin delle funzioni timer/clock dell’ATmega32U4 MCU. La tilde (~) indica un pin active-low (low = true). Sull’ATmega32U4 non ci sono i pin T3 e T4. Soltanto i timer/contatori 0 e 1 hanno a disposizione i pin T0 e T1. Le assegnazioni dei pin sono illustrate nella Figura 3-20. Tabella 3-23 - I pin del timer/clock.
Pin
Porta
Funzione
Pin
Porta
Funzione
12
PB7
OC0A/OC1C
29
PB5
OC1A/~OC4B
18
PD0
OC0B
30
PB6
OC1B/OC4B
25
PD4
ICP1
31
PC6
OC3A/OC4A
26
PD6
T1/~OC4D
32
PC7
ICP3/~OC4A
Figura 3-20 - I pin del timer/contatore sull’ATmega32U4.
Gli interrupt esterni
Le assegnazioni degli interrupt dei pin sull’ATmega32U4 MCU sono elencate nella Tabella 3-24 e mostrate nella Figura 3-21. Tabella 3-24 - I pin degli interrupt esterni.
Pin
Porta
Funzione
Pin
Porta
Funzione
8
PB0
PCINT0
12
PB7
PCINT7
9
PB1
PCINT1
18
PD0
INT0
10
PB2
PCINT2
19
PD1
INT1
11
PB3
PCINT3
20
PD2
INT2
28
PB4
PCINT4
21
PD3
INT3
29
PB5
PCINT5
1
PE6
INT6
Figura 3-21 - I pin degli interrupt esterni sull’ATmega32U4.
I pin da PD0 a PD3 della porta D e il pin PE6 della porta E sono pensati espressamente per essere utilizzati come input per gli interrupt esterni. Anche tutti i pin compresi tra PCINT0 e PCINT7 possono essere utilizzati come input per gli interrupt esterni senza interferire con altre funzioni assegnate (trovate una panoramica di come possono essere utilizzati questi interrupt in “Gli interrupt” a pagina 26).
L’interfaccia USB 2.0
L’ATmega32U4 incorpora un’interfaccia USB 2.0 a piena velocità, ma non può fungere da host USB, soltanto come dispositivo. Mette a disposizione diversi endpoint interni con buffer FIFO configurabili. Un PLL integrato sul chip genera un clock da 48 MHz per l’interfaccia USB e l’input del PLL può essere configurato in modo da utilizzare un oscillatore esterno, una fonte di clock esterna, oppure una fonte di clock RC interna. L’output da 48 MHz del PLL si utilizza per generare una piena velocità di 12 MHz oppure un clock a bassa velocità da 1,5 MHz. Notate che i pin USB dell’ATmega32U4 non sono associati a una porta, ma soltanto alla logica USB interna e al circuito di regolazione della tensione. Le assegnazioni dei pin I/O USB sono elencate nella Tabella 3-25 e mostrate nella Figura 3-22. Tabella 3-25 - Gli I/O USB.
Pin
Funzione
Pin
Funzione
2
USB UVCC
5
USB UGnd
3
USB D–
6
USB UCap
4
USB D+
7
USB VBus
Figura 3-22 - I pin USB dell’ATmega32U4.
Le caratteristiche elettriche La Tabella 3-26 mostra le caratteristiche elettriche massime dell’ATmega32U4 e la Tabella 3-27 mostra i parametri di consumo energetico di base.
Tabella 3-26 - Le caratteristiche massime dell’ATmega32U4.
Parametro
Valori
Unità
Da -0,5 a VCC +0,5
V
Tensione pin reset
Da -0,5 a +13,0
V
Tensione pin VBUS
Da -0,5 a +6,0
V
Dispositivo VCC V
6,0
V
Corrente DC pin I/O
40,0
mA
Corrente VCC
200,0
mA
Tensione pin I/O
Tabella 3-27 - Il consumo energetico dell’ATmega32U4.
Parametro Corrente di alimentazione Modalità risparmio energetico
Condizione
VCC
Tipico
Massimo
Attivo 8 MHz
5 V
10 mA
15 mA
Inattivo 8 MHz
5 V
WDT attivato
3 V
<10 uA
12 uA
WDT disattivato
3 V
1 uA
5 uA
6 mA
Le assegnazioni dei pin di Arduino La scheda Arduino Leonardo usa la versione estesa del layout di base, che include ulteriori pin. I pin dell’interfaccia USB sono collegati direttamente al connettore USB sulla PCB e i segnali USB non vengono riportati sui pin-socket degli header ai lati della PCB.. Il layout della scheda Leonardo è descritto nel Capitolo 4. Nella Tabella 3-28 trovate la mappatura dei pin del chip su quelli della scheda Leonardo. Notate che non tutti i pin dell’ATmega32U4 sono estratti e alcuni dei pin di input ADC sono utilizzati come pin I/O digitali e discreti. Tabella 3-28 - La mappatura dei pin di Leonardo sull’ATmega32U4.
Pin di Leonardo
Pin del chip
Funzioni
Pin di Leonardo
Pin del chip
0
20
RXD1/INT2
11
12
PCINT7/OC0A/OC1C
1
21
TXD1/INT3
12
26
T1/OC4D/ADC9
2
19
SDA/INT1
13
32
ICP3/CLK0/OC4
3
18
OC0B/SCL/INT0
A0
36
ADC7/TDI
4
25
ICP1/ADC8
A1
37
ADC6/TD0
Funzioni
5
31
OC3A/OC4A
A2
38
ADC5/TMS
6
27
T0/OC4D/ADC10
A3
39
ADC4/TCK
7
1
INT6/AIN0
A4
40
ADC1
8
28
PCINT4/ADC11
A5
41
ADC0
9
29
PCINT5/OC1A/OC4B/ADC12
AREF
42
AREF
I fuse bit Per impostare vari parametri come la sorgente del clock, i divisori del timer, i blocchi di accesso alla memoria e così via, le MCU AVR utilizzano una serie di cosiddetti fuse. Potete immaginarli come un gruppo di interruttori. In questo paragrafo daremo un’occhiata ai fuse bit dell’ATmega168/328. Questa e la MCU utilizzata nelle schede Duemilanove, Mini, Nano e Uno e di solito nei progetti AVR si utilizza la versione DIP (dual in-line pin). I concetti generali valgono anche per l’ATmega1280/2560 e l’ATmega32U4. Nell’ATmega168/328 per i fuse bit ci sono tre byte: low, high ed extended. Un fuse bit si imposta su zero quando viene programmato (cioè, sono logica active-low). Le Tabelle 329, 3-30 e 3-31 elencano i fuse bit dell’AVR e le loro funzioni. Tabella 3-29 - I byte dei fuse low.
Nome del bit
N° del bit
Descrizione
Valore pred.
Nome del bit
N° del bit
Descrizione
Valore pred.
CKDIV8
7
Clock diviso per 8
0
CKSEL3
3
Sorgente del clock
0
CKOUT
6
Output del clock
1
CKSEL2
2
Sorgente del clock
0
SUT1
5
Momento di avvio
1
CKSEL1
1
Sorgente del clock
1
SUT0
4
Momento di avvio
0
CKSEL0
0
Sorgente del clock
0
Tabella 3-30 - I byte dei fuse high.
Nome del bit
N° del bit
Descrizione Disattiva
Valore pred.
Nome del bit
N° del bit
Descrizione EEPROM
Valore pred.
RSTDISBL
7
DWEN
6
SPIEN
WDTON
reset esterno
1
EESAVE
3
preservata
1
Attiva debugWIRE
1
BODLEVEL2
2
Livello frigger BOD
1
5
Attiva download SPI
0
BODLEVEL1
1
Livello frigger BOD
1
4
Timer watchdog attivo
1
BODLEVEL0
0
Livello frigger BOD
0
Tabella 3-31 - I byte dei fuse extended.
Nome del bit
N° del bit
Descrizione
Valore pred.
Nome del bit
N° del bit
Descrizione
Valore pred.
-
7
-
1
-
3
-
1
-
6
-
1
BOOTSZ1
2
Dimensione del boot
0
-
5
-
1
BOOTSZ0
1
Dimensione del boot
0
-
4
-
1
BOOTRST
0
Vettore di reset
1
Per il routing dell’input e dell’output del clock, l’AVR utilizza una logica detta “AVR Clock Control Unit”, come mostra la Figura 3-23. I nomi “clk” del timing route si riferiscono alla funzione di timing di ciascun percorso. Trovate maggiori dettagli sulla scheda tecnica dell’ATmega328 di Atmel (http://bit.ly/mc-atmega328). Il multiplexer del clock può essere configurato con i fuse bit CKSEL(3:0), oppure con il nibble di 4 bit meno significativo. La Tabella 3-32 elenca le possibili opzioni di sorgenti di clock e i valore dei fuse bit CKSEL.
Figura 3-23 - Il sottosistema di controllo e distribuzione dell’AVR.
Tabella 3-32 - Selezionare la sorgente del clock utilizzando fuse bit CKSEL.
Sorgente del clock
CKSEL(3:0)
Sorgente del clock
CKSEL(3:0)
Low power crystal
1111 - 1000
Calibrato interno
0010
Full swing crystal
0111 - 0110
Clock esterno
0000
Low frequency crystal
0101 - 0100
Non utilizzato (riservato)
0001
Notate che le sorgenti di clock al cristallo offrono ulteriori opzioni, a seconda di come sono impostate. Nel Capitolo 10 utilizzeremo questi fuse bit per configurare un AVR nuovo di zecca su una PCB personalizzata. In un dispositivo o sistema basato su Arduino probabilmente i bit CKSEL non dovrebbero essere alterati, ma altri fuse bit possono essere impostati in modo che forniscano funzioni utili. Nel fuse byte high, i fuse bit WDTON e BODLEVEL possono essere utilizzati per attivare il timer watchdog dell’AVRe impostare il livello di risposta BOD (brown-out detection). Sia il timer watchdog che il circuito brown-out detection causano un reset della MCU. In watchdog si rivela spesso molto utile, specie in situazioni nelle quali un errore di qualche tipo può provocare problemi più gravi. Se il registro di controllo del watchdog viene resettato prima del time-out, di solito nel ciclo principale, non aziona un interrupt.
Se qualche parte del codice smette di rispondere, il ciclo principale si interrompe e il timer termina. Per il controllo del watchdog, avr-libc mette a disposizione le funzioni wdt_enable(), wdt_disable() e wdt_reset(). La brown-out detection genera un interrupt se l’alimentazione DC del VCC cade al di sotto di una determinata soglia. Questo può dare tempo sufficiente per salvare dati importanti su una memoria flash collegata oppure per cambiare alcuni output digitali discreti. I fuse bit possono essere impostati utilizzando strumenti di programmazione come quelli descritti in “La programmazione in-system” a pagina 150 nel Capitolo 6. Il riquadro “Impostare i fuse bit della MCU AVR per un cristallo a 16 MHz” a pagina 420 descrive come si impostano i fuse bit di una MCU AVR in modo che funzioni con un clock da 16 MHz. Questo non è stato che uno sguardo rapido sui fuse bit. Come sempre, per trovare le descrizioni dettagliate del timer watchdog e dei livelli di brown-out detection, potete consultare la documentazione di Atmel.
Per ulteriori informazioni Il Capitolo 2 contiene le panoramiche delle funzioni periferiche interne che si trovano nei microcontroller AVR. Il Capitolo 4 contiene i pinout delle schede Arduino per le funzioni della MCU AVR. Per informazioni dettagliate sulle funzioni periferiche interne dei microcontroller AVR, potete consultare questi documenti di Atmel (disponibili sul sito web di Atmel, sotto Support→Datasheets): •
Datasheet: ATmega48PA/ATmega88PA/ATmega168PA/ATmega328P 8 bit Microcontroller with 4/8/16/32K Bytes In-System Programmable Flash
•
Datasheet: Atmel ATmega640/V-1280/V-1281/V-2560/V-2561/V 8 bit Atmel Microcontroller with 16/32/64KB In-System Programmable Flash
•
Datasheet: ATmega16U4/ATmega32U4 8 bit Microcontroller with 16/32K Bytes di ISP Flash and USB Controller
4 I dettagli tecnici di Arduino
Questo capitolo descrive le caratteristiche generali, fisiche ed elettriche, di specifiche schede Arduino, dalla Diecimila fino ai tipi più recenti come la Leonardo, la Esplora e la Micro. Gli argomenti trattati comprendono le descrizioni dei pinout e le dimensioni fisiche della maggior parte degli attuali modelli di Arduino, dai tipi più classici come la Uno, alle schede con un fattore di forma superiore come la Mega e l’unica Esplora, a quelle più compatte come i modelli Mini, Micro e Nano.
Caratteristiche e funzionalità di Arduino La Tabella 4-1 mette a confronto i tipi più diffusi di schede Arduino. Se confrontate questa tabella con quelle del Capitolo 1, notate chiaramente che le funzionalità di base di una scheda Arduino sono quelle fornite dal suo microcontroller. Tuttavia, dal momento che i design di Arduino allocano determinati pin dei processori AVR a determinate funzioni, oppure non mettono a disposizione tutti i pin del processore, non tutte le funzionalità dei microcontroller sono disponibili sui terminali di Arduino. Tabella 4-1 - Le funzionalità hardware di Arduino.
VCC (V)
Clock (MHz)
Pin AINa
Pin DIOb
Pin PWM
ATmega328
5
16
6
14
6
Nessuno
Duemilanove
ATmega168
5
16
6
14
6
Normale
Duemilanove
ATmega328
5
16
6
14
6
Normale
Diecimila
ATmega168
5
16
6
14
6
Normale
Esplora
ATmega32U4
5
16
-
-
-
Micro
Ethernet
ATmega328
5
16
6
14
4
Normale
Fio
ATmega328P
3,3
8
8
14
6
Mini
Leonardo
ATmega32U4
5
16
12
20
7
Micro
LilyPad
ATmega168V
2,7–
8
6
14
6
Nessuno
Nome della scheda
Processore
ArduinoBT
USBc
5,5 LilyPad
ATmega328V
2,7– 5,5
8
6
14
6
Nessuno
Mega
ATmega1280
5
16
16
54
15
Normale
Mega ADK
ATmega2560
5
16
16
54
15
Normale
Mega 2560
ATmega2560
5
16
16
54
15
Normale
Micro
ATmega32U4
5
16
12
20
7
Micro
Mini
ATmega328
5
16
8
14
6
Nessuno
Mini Pro
ATmega168
3,3
8
6
14
6
Nessuno
Mini Pro
ATmega168
5
16
6
14
6
Nessuno
Nano
ATmega168
5
16
8
14
6
Mini-B
Nano
ATmega328
5
16
8
14
6
Mini-B
Pro (168)
ATmega168
3,3
8
6
14
6
Nessuno
Pro (328)
ATmega328
5
16
6
14
6
Nessuno
Uno
ATmega328
5
16
6
14
6
Normale
Yún
ATmega32U4
5
16
12
20
7
Host (A)
a Input analogici. b I/O digitali. c Output pulse-width modulation (alternano funzioni pin DIO).
NOTA In questo e altri paragrafi si utilizza il termine “pin” quando ci si riferisce ai pin socket di Arduino. Lo facciamo soprattutto per mantenerci fedeli alla terminologia che si trova altrove, ma tecnicamente non è del tutto corretta. I punti di connessione sulla scheda Arduino sono socket e i pin veri e propri sono i jumper e le shield che si inseriscono in queste prese. Potete immaginare un “pin” come un punto di connessione di qualche tipo, che sia un terminale di un circuito integrato, una posizione terminale di una presa di un header da 0,1 pollici (2,54 mm), oppure i pin che si estendono dalla base di una PCB shield.
Le interfacce USB di Arduino A partire dalla scheda Leonardo (2012), come processore principale viene utilizzato il microcontroller ATmega32U4 XMEGA. Questo componente è dotato di un’interfaccia USB integrata, che elimina la necessità di un ulteriore chip come sui modelli precedenti di Arduino con un’interfaccia USB. Tutte le schede Leonardo (2012), Esplora (2012), Micro (2012) e Yún (2013) utilizzano il processore ATmega32U4. I modelli più vecchi di Arduino con USB utilizzavano un’interfaccia FTDI (il chip FT232RL), un ATmega8 (Uno), oppure un ATmega16U2 (Mega2560 e Uno R3). Il FT232RL esegue le conversioni tra seriale standard (come RS-232) e USB. Nelle
schede Uno, Uno R3 e Mega2560, gli ulteriori piccoli processori ATmega sono preprogrammati in modo che fungano da interfaccia USB. L’operazione di questi componenti è trasparente quando si utilizza l’IDE di Arduino per creare e caricare gli sketch dei programmi. Le schede che non sono dotate di interfaccia USB devono essere programmate utilizzando un adattatore esterno. Internamente, i tipi di Arduino che utilizzano l’interfaccia seriale-USB FTDI FT232RL sono essenzialmente identici e consistono di un circuito di regolazione della tensione DC e di due IC. La Figura 4-1 mostra il diagramma a blocchi dei modelli Diecimila e Duemilanove con interfaccia FTDI.
Figura 4-1 - L’interfaccia USB FTDI.
A partire circa dal 2010, per l’interfaccia USB le schede Uno R2 e Uno SMD hanno cominciato a utilizzare l’ATmega16U2, anziché la FTDI FT232RL. Anche la Uno R3 ha l’ATmega16U2, che funge da interfaccia USB. L’ATmega16U2 incorpora un’interfaccia USB integrata e fondamentalmente è uguale all’ATmega32U4, ma con meno memoria. La Figura 4-2 mostra il diagramma a blocchi di una scheda Uno R2 con un ATmega16U2 che fornisce l’interfaccia USB. La Uno, con un ATmega8, internamente presenta la
stessa organizzazione funzionale della Uno R2, ma con una MCU diversa che funge da interfaccia USB.
Le dimensioni fisiche di Arduino Le schede Arduino si trovano in una vasta gamma di forme e dimensioni, ma in genere tendono a essere organizzate in quattro gruppi: le schede di base, le mega, quelle con un fattore di forma piccolo e quelle per scopi speciali.
Figura 4-2 - L’interfaccia USB dell’ATmega16U2.
NOTA Le dimensioni delle schede segnalate in questo paragrafo, anche se vi si avvicinano molto, in genere sono approssimate, dal momento che possono esserci piccole variazioni a seconda del fornitore. Se vi servono le dimensioni precise, potete consultare i layout delle PCB su Arduino.cc, dove ne trovate uno per ciascuna scheda. Oppure, meglio ancora, potete misurare una scheda vera e propria.
Per farvi un’idea della scala, la Figura 4-3 mostra diverse schede Arduino molto diffuse. In senso antiorario a partire dall’angolo in basso a sinistra, vedete una Duemilanove, una Leonardo, un clone della Mega2560 di SainSmart con un layout di pin I/O esteso e una Mega2560 ufficiale di Arduino, con una Arduino Nano al centro.
Figura 4-3 - Confronto di schede Arduino e cloni.
I tipi di PCB Arduino di base La Figura 4-4 mostra i layout fisici di sei diverse schede Arduino di base, dalla Diecimila alla Leonardo. Nel mezzo compaiono le varianti Duemilanove e Uno. In questo contesto, “di base” si riferisce al layout della PCB Arduino “classica”, che determina il design fisico della maggior parte delle shield e degli altri componenti aggiuntivi. Le funzioni degli I/O e degli altri pin su ciascuna PCB sono descritte in “Le configurazioni del pinout di Arduino” a pagina 78.
Figura 4-4 - I tipi di PCB Arduino di base.
Nel caso delle schede Diecimila, Duemilanove, Uno R2 (revisione 2) e Uno SMD, la disposizione delle prese I/O sugli header ai bordi delle PBC non cambia. Quando parla del fattore di forma dell’Arduino di base, questo libro si riferisce a questo. Inoltre, a partire dalla Uno R2, sulla PCB appare un nuovo blocco di sei pin, in aggiunta a quello che esisteva già sulle schede precedenti. Si tratta dell’interfaccia ICSP (In-Circuit Serial Programming) del processore ATmega16U2, che si utilizza per l’interfaccia USB. Anche la Uno SMD è dotata di questa nuova interfaccia ICSP. La Uno R3 ha introdotto la nuova configurazione estesa di pin I/O. Si tratta di un’estensione retrocompatibile, che significa che le shield pensate per i modelli precedenti come il Duemilanove funzionano lo stesso sulle nuove schede. L’estensione non fa altro che aggiungere nuovi pin-socket di segnale, ma nessun segnale nuovo, e non altera nessuna delle funzioni dei pin che si trovano sul layout di base. La PCB Leonardo utilizza il processore ATmega32U4, che offre il supporto USB integrato, per cui su una PCS Leonardo ci sono soltanto un microcontroller IC e soltanto una porta ICSP. Il layout dei pin I/O è uguale a quello delle schede precedenti, anche se le porte vere e proprie del microcontroller utilizzate sono diverse. Tutte le schede Arduino di base hanno le stesse dimensioni fisiche, come mostra la
Figura 4-5. Le posizioni dei fori di montaggio della PCB variano da modello a modello, a seconda della versione della scheda, ma le dimensioni esterne della scheda in generale sono le stesse.
Figura 4-5 - Le dimensioni delle schede di base ed estesa.
I tipi di PCB Arduino con fattore di forma Mega Le schede con fattore di forma Mega incorporano il pinout di base insieme a ulteriori pin per adattarsi alle capacità aggiuntive dei microcontroller ATmega1280 e ATmega2560 (questi dispositivi sono descritti in “L’ATmega1280/ATmega2560” a pagina 39 nel Capitolo 3).
Le schede Mega e Mega2560 Le schede Mega e Mega2560 presentano essenzialmente lo stesso layout e la differenza principale tra di loro è il tipo di dispositivo AVR sulle schede. La Mega2560 sostituisce la Mega, che non viene più prodotta da Arduino.cc, anche se si possono ancora trovare alcune schede cloni second-source. Se si pensa alla memoria più potente della Mega2560, davvero non ci sono motivi per acquistare una Mega. La Figura 4-6 mostra le dimensioni complessive delle schede Mega o Mega2560. Notate che sulle schede Mega funzionano le shield per quelle di base (Uno, Leonardo,
ecc.). Sulla Mega, i pin I/O sono organizzati in modo che gli I/O digitali di base e gli input A/D dallo 0 al 5 siano compatibili con il layout dei pin di base.
Figura 4-6 - Le dimensioni della Mega e della Mega2560.
La Mega ADK La Mega ADK si basa sulla Mega2560, ma mette a disposizione un’interfaccia USB host che permette di collegarla a telefoni Android e dispositivi simili. A parte che per il connettore USB addizionale che si trova tra il connettore USB di tipo B e la presa di corrente continua, in termini di dimensioni è identica alla Mega2560. Come nel caso della Mega2560, con la Mega ADK è possibile utilizzare shield standard di tipo base.
I tipi di PCB Arduino con fattore di forma piccolo Le schede Arduino di dimensione “normale” sono state le prime ad apparire intorno al 2005 e prima del 2007 il loro layout e quello esteso sono diventate le forme che si utilizzano oggi. Ma il team di Arduino e i suoi partner si sono accorti che la scheda di dimensione normale non si rivelava ideale per alcune applicazioni e quindi ne inventarono alcuni formati in miniatura. Le schede in miniatura sono i layout Mini, Micro, Nano e Fio. Queste PCB presentano sia la lunghezza che la larghezza ridotte, ma sono comunque dotate di processori AVR
come quelle di dimensioni normali.
La Mini La Mini è pensata per essere utilizzata sulle breadboard oppure in altre applicazioni dove lo spazio sia limitato. Non è dotata di connettore USB e per trasferire codice eseguibile sul microcontroller è necessario utilizzare un’interfaccia esterna. La sue dimensioni sono mostrate nella Figura 4-7.
Figura 4-7 - Le dimensioni dell’Arduino Mini.
La Pro Mini La Pro Mini è simile alla Mini per quanto riguarda il layout dei pin e il fattore di forma, ma, a differenza della Mini, è pensata per installazioni permanenti o semipermanenti. La Pro Mini è stata progettata e prodotta da SparkFun Electronics. La sue dimensioni sono mostrate nella Figura 4-8.
Figura 4-8 - Le dimensioni dell’Arduino Pro Mini
La Nano Simile alla Mini, la Nano è una scheda dal fattore di forma ridotto, adatta per essere utilizzata con breadboard che non richiedono saldature oppure come modulo aggiuntivo per PCB più grandi. È stata progettata e prodotta da Gravitech. Le sue dimensioni sono fornite nella Figura 4-9.
Figura 4-9 - Le dimensioni dell’Arduino Nano.
La Fio La Fio è pensata per applicazioni wireless, principalmente XBee, pertanto le mancano alcune delle funzionalità di programmazione per mezzo di collegamento diretto delle
quali sono dotati altri tipi di Arduino. Una Fio può essere programmata utilizzando un adattatore seriale-USB, oppure via wireless utilizzando un adattatore USB-XBee. È stata progettata e prodotta da SparkFun Electronics; La sue dimensioni sono mostrate nella Figura 4-10.
Figura 4-10 - Le dimensioni dell’Arduino Fio.
La Micro La Micro utilizza un fattore di forma DIP (dual in-line pin) e un processore ATmega32U4, identico a quello della scheda Leonardo. Come nel caso della Nano, la Micro è adatta per essere utilizzata con la breadboard che non richiede saldature e come modulo aggiuntivo utilizzando una normale presa IC. È stata sviluppata in collaborazione con Adafruit. Le dimensioni della Micro sono mostrate nella Figura 4-11.
Figura 4-11 - Le dimensioni dell’Arduino Micro.
I tipi di PCB per scopi speciali Le schede Arduino non devono necessariamente presentare semplici forme rettangolari. La LilyPad è un piccolo disco con i punti di connessione organizzati intorno ai bordi e può essere integrata nei tessuti per costruire creazioni da indossare. Fisicamente, la Esplora è configurata come un normale game controller, anche se in realtà si tratta di un Arduino che si può programmare in modo che faccia molto più che semplicemente permettere di giocare.
La LilyPad
La LilyPad e le sue variazioni sono pensate per applicazioni da indossare. La scheda in sé misura circa 2 pollici (50 mm) di diametro, come mostra la Figura 4-12.
Figura 4-12 - Le dimensioni dell’Arduino LilyPad.
La Esplora La Esplora mette a disposizione quattro pulsanti a pressione, un joystick tipo interruttore e un connettore USB micro. Quattro fori di montaggio sono disponibili per fissare la scheda a uno chassis o a un pannello. Le dimensioni della PCB Esplora sono mostrate nella Figura 4-13.
Figura 4-13 - Le dimensioni dell’Arduino Esplora.
Le configurazioni del pinout di Arduino Quando si crea una scheda shield per Arduino, la convenzione è seguire il layout dei pin di base descritto qui. Questa configurazione si trova sulle schede “standard” Arduino di base costruite tra il 2007 e il 2012. Anche le schede che utilizzano il layout dei pin “esteso”, più recente (la Uno R3 e la Leonardo), oltre alle schede “Mega”, supportano le connessioni di base, ma vi aggiungono ulteriori capacità estendendo le righe di terminali sui lati delle PCB.
Il layout dei pin dell’Arduino di base Il layout dei pin dell’Arduino di base che esiste oggi è apparso con il modello Diecimila. Nel corso degli anni, è diventato de facto lo standard sul quale si basano diverse schede. Le schede Arduino che utilizzano il layout di base dei pin sono elencate nella Tabella 4-2. Tabella 4-2 - Le schede Arduino con il layout di base.
Nome della scheda
Anno
Microcontroller
Diecimila
2007
ATmega168
Duemilanove
2008
ATmega168/ATmega328
Uno (R2 e SMD)
2010
ATmega328P
La Figura 4-14 mostra il pinout di una scheda Arduino di base, che include i modelli Diecimila, Duemilanove, Uno R2 e Uno SMD. Le caselle grigie nella Figura 4-14 indicano il numero del pin del chip e le assegnazioni delle porte nei componenti ATmega168/328.
Figura 4-14 - Le funzioni dei delle schede Arduino standard.
Il layout dei pin comune degli I/O e dell’alimentazione su Arduino consiste di 14 pin I/O digitali e discreti, un riferimento analogico, 3 pin per la messa a terra, 6 pin per gli ingressi analogici, i pin per 3,3 V e 5 V e una linea di reset. Come mostra la Figura 414, questi pin sono disposti come connettori a otto posizioni e due connettori a sei posizioni sui lati della PCB. Dal punto di vista della programmazione, sulla PCB Diecimila, Duemilanove, Uno R2, oppure Uno SMD il pin di ciascuna interfaccia ha un nome predefinito, che si utilizza per identificarlo nel software. Questi nomi sono rivelati dalle etichette stampate sulla PCB Arduino. La Tabella 4-3 elenca le assegnazioni dei pin delle schede Arduino di base o R2 con MCU ATmega168 o ATmega328. Vedere le assegnazioni dei pin per l’Arduino Ethernet (Tabella 4-3) per la scheda Uno SMD. Tabella 4-3 - Le assegnazioni dei pin sull’Arduino ATmega168/328.
Pin digitale (Dn)
Pin analogico (An)
Pin AVR
Porta AVR
Funzione/i AVR
0
2
PD0
RxD
1
3
PD1
TxD
2
4
PD2
INT0
3
5
PD3
INT1, OC2B
4
6
PD4
T0, XCK
5
11
PD5
T1
Sì
6
12
PD6
AIN0
Sì
7
13
PD7
AIN1
PWM AVR
Sì
8
14
PB0
CLK0, ICP1
9
15
PB1
OC1A
Sì
10
16
PB2
OC1B, SS
Sì
11
17
PB3
OC2A, MOSI
Sì
12
18
PB4
MISO
13
19
PB5
SCK
14
0
23
PC0
15
1
24
PC1
16
2
25
PC2
17
3
26
PC3
18
4
27
PC4
SDA
19
5
28
PC5
SCL
Il layout dei pin esteso di base A partire dalla versione R3 della Uno, sulla PCB Arduino sono apparsi altri quattro pin. Due di questi si trovano accanto al pulsante di reset, che ha cambiato posizione, e mettono a disposizione ulteriori connessioni per I2C (le linee SCL e SDA). Gli altri due sono apparsi accanto alla connessione di reset sul lato opposto della scheda. Uno è pensato come IOREF (la tensione I/O nominale, che può essere 3,3 V oppure 5 V a seconda del tipo di scheda) e l’altro per adesso non è collegato. La Tabella 4-4 elenca le schede di base con il layout esteso. Tabella 4-4 - Le schede Arduino con il layout esteso.
Nome della scheda
Anno
Microcontroller
Uno R3
2010
ATmega328
Ethernet
2011
ATmega328
Leonardo
2012
ATmega32U4
La Uno R3 Come la Uno R2 e la Uno SMD, per gestire le comunicazioni USB la Uno R3 utilizza un secondo microcontroller. L’Arduino Ethernet non dispone di USB integrata. La Figura 415 mostra il diagramma a blocchi delle schede Uno R3 e Uno SMD.
Figura 4-15 - L’interfaccia USB dell’ATmega16U2.
Le funzioni dei pin della Uno R3 sono mostrate nella Figura 4-16.
Figura 4-16 - Le funzioni dei pin della Uno R3.
Le schede Arduino estese di base (R3) con MCU ATmega328 presentano le stesse assegnazioni dei pin mostrate nella Tabella 4-3, ma con gli ulteriori pin per ADC4 e ADC5 (A4 e A5). Le funzioni dei pin sulla Leonardo sono definite in “La Leonardo” a pagina 84.
La Ethernet La Ethernet si discosta dalle convenzioni di Arduino viste fino alla Uno R3, con la sua inclusione di un’interfaccia Ethernet da 100Mb e di un connettore RJ45. È priva di interfaccia USB. La MCU è una versione a montaggio superficiale dell’ATmega328, con funzioni dei pin e numerazioni diverse rispetto all’ATmega328. Per l’interfaccia Ethernet si utilizza un chip WIZnet W5100. La Figura 4-17 mostra un diagramma a blocchi della scheda Ethernet.
Figura 4-17 - Il diagramma a blocchi dell’Arduino Ethernet.
Per programmare la Ethernet si utilizza un’interfaccia di tipo FTDI con un adattatore, come i dispositivi FTDI di SparkFun oppure di Adafruit. Questa interfaccia presenta un header da sei pin ad angolo retto sul bordo della PCB, accanto al lettore microSD. La Figura 4-18 mostra i pinout della scheda Ethernet.
Figura 4-18 - Le funzioni dei pin sulla scheda Arduino Ethernet.
Questo prodotto è stato ritirato da Arduino.cc, ma si trova ancora presso diversi fornitori. La connettività Ethernet può essere ottenuta utilizzando una shield Ethernet (trovate maggiori dettagli sulle shield nel Capitolo 8). La Tabella 4-5 elenca le assegnazioni dei pin per l’Arduino Ethernet. Notate che i pin 10, 11, 12 e 13 sono riservati per l’interfaccia Ethernet e non sono disponibili per essere utilizzati per scopi generali. Tabella 4-5 - Le assegnazioni dei pin dell’Arduino Ethernet.
Pin digitale (Dn)
Pin analogico (An)
Pin AVR
Porta AVR
Funzione/i AVR
0
30
PD0
RxD
1
31
PD1
TxD
2
32
PD2
INT0
3
1
PD3
INT1, OC2B
4
2
PD4
T0, XCK
PWM AVR
Sì
5
9
PD5
T1, OC0B
Sì
6
10
PD6
AIN0, OC0A
Sì
7
11
PD7
AIN1
8
12
PB0
CLK0, ICP1
9
13
PB1
OC1A
Sì
10
14
PB2
OC1B, SS
Sì
11
15
PB3
OC2A, MOSI
Sì
12
16
PB4
MISO
13
17
PB5
SCK
14
0
23
PC0
15
1
24
PC1
16
2
25
PC2
17
3
26
PC3
18
4
27
PC4
SDA
19
5
28
PC5
SCL
La Leonardo La Leonardo ha introdotto il processore ATmega32U4, che contiene un’interfaccia USB integrata e funzionalità migliorate. Questo ha semplificato il layout della PCB, come potete osservare nella Figura 4-19. Inoltre, notate che la Leonardo utilizza un connettore mini-USB anziché quello di tipo B e dimensione normale che si trova sulle schede Arduino precedenti. Si trattava di una modifica piuttosto necessaria, che permette alla Leonardo di lavorare con shield che avrebbero interferito con il connettore USB di tipo B sui modelli più vecchi. La Uno R3 e la Leonardo utilizzano entrambi lo stesso layout di pin della PCB, ma alcune delle funzioni del microcontroller sono differenti. Nell’IDE di Arduino, questo si gestisce utilizzando una serie di definizioni specifiche per ciascun tipo di scheda, per mappare funzioni su determinati pin.
Figura 4-19 - Le funzioni dei pin sulla scheda Arduino Leonardo.
La Tabella 4-6 elenca le assegnazioni dei pin per un Arduino esteso o R3 con MCU ATmega32U4. Tabella 4-6 - Le assegnazioni dei pin dell’Arduino ATmega32U4.
Pin digitale (Dn)
Pin analogico (An)
Pin AVR
Porta AVR
Funzione/i AVR
0
20
PD2
INT3, RxD1
1
21
PD3
INT2, TxD1
2
19
PD1
INT1, SDA
3
18
PD0
INT0, OC0B, SCL
4
25
PD4
ICP1, ADC8
5
31
PC6
OC3A, OC4A
Sì
6
27
PD7
OC4D, ADC10, T0
Sì
PWM AVR
Sì
7
1
PE6
INT6, AIN0
8
28
PB4
ADC11 Sì
9
29
PB5
OC1A, ADC12, *OC4B
10
30
PB6
OC1B, ADC13, OC4B
Sì
11
12
PB7
OC0A
Sì
12
26
PD6
*OC4D, ADC9, T1
Sì
13
32
PC7
OC4A, ICP3
Sì
14
0
36
PF7
TDI
15
1
37
PF6
TDO
16
2
38
PF5
TMS
17
3
39
PF4
TCK
18
4
40
PF1
19
5
41
PF0
Il layout dei pin sulla serie Mega Anche la serie Mega (che utilizza i processori ATmega1280 e ATmega2560) incorpora il modello di pinout standard, ma include altri pin per accogliere le ulteriori capacità I/O estese dei processori più grandi. Il layout dei pin della serie Mega è mostrato nella Figura 4-20. Le schede che utilizzano questo layout sono elencate nella Tabella 4-7. Con le schede Mega si possono utilizzare la maggior parte delle shield più comuni.
Figura 4-20 - Le funzioni dei pin sulle schede della serie Arduino Mega.
Tabella 4-7 - Il layout dei pin delle schede Mega.
Nome della scheda
Anno
Microcontroller
Mega
2009
ATmega1280
Mega2560
2010
ATmega2560
Mega ADK
2011
ATmega2560
NOTA Nella Figura 4-20, le funzioni PCINT dei pin non sono mostrate per rendere l’immagine più chiara. Notate anche che la versione R3 della Mega2560 contiene pin che non si trovano sulle versioni precedenti, ma che non interferiscono con le shield con un layout di base.
I layout non standard
In termini di configurazioni dei pin non standard (non standard nel senso che sono fisicamente incompatibili con le shield Arduino convenzionali), la più radicale è la LilyPad, con il suo fattore di forma circolare e per il fatto che per le connessioni utilizza piazzole di saldatura. Le schede con un fattore di forma ridotto come la Nano, la Mini, la Mini Pro e la Micro hanno i pin saldati sul lato posteriore della scheda e sono adatte per essere utilizzate con una breadboard che non richiede saldature, oppure come componenti su una PCB più grande. La Fio utilizza piazzole di saldatura con una spaziatura compatibile con le pin strip standard e la Esplora ha un fattore di forma di tipo game controller. Nessuna delle schede con layout non standard può essere utilizzata direttamente con una shield standard. Le schede che ricadono in questa categoria sono elencate nella Tabella 4-8 e le funzioni dei pin relative a queste schede sono mostrate nelle Figure dalla 4-21 alla 4-27 nei prossimi paragrafi. Tabella 4-8 - Le schede con il layout del pin non standard.
Nome della scheda
Anno
Microcontroller
LilyPad
2007
ATmega168V/ATmega328V
Nano
2008
ATmega328/ATmega168
Mini
2008
ATmega168
Pro Mini
2008
ATmega328
Fio
2010
ATmega328P
Esplora
2012
ATmega32U4
Micro
2012
ATmega32U4
La LilyPad
Figura 4-21 - Le funzioni dei pin sull’Arduino LilyPad.
La Nano
Figura 4-22 - Le funzioni dei pin sulla Nano.
La Mini
Figura 4-23 - Le funzioni dei pin sulla Mini.
La Pro Mini
Figura 4-24 - Le funzioni dei pin sulla Pro Mini.
La Fio
Figura 4-25 - Le funzioni dei pin sulla Fio.
La Esplora
Figura 4-26 - Le funzioni dei pin sulla Esplora.
La Micro
Figura 4-27 - Le funzioni dei pin sulla Micro.
Per ulteriori informazioni Il sito web di Atmel (http://www.atmel.com/avr) mette a vostra disposizione una selezione di schede tecniche, software di esempio e altre sorgenti per lavorare con i microcontroller AVR. Notate che questi materiali sono relativi ad AVR, non ad Arduino. Trovate ulteriori informazioni sulle varie schede Arduino sul sito web di Arduino (http://www.arduino.cc).
5 Programmare Arduino e i microcontroller AVR
Questo capitolo è un ambizioso tour di alto livello degli strumenti, dei concetti e delle tecniche che si possono utilizzare per creare, compilare, assemblare e caricare software su Arduino. Qui troverete molti concetti profondi trattati a grandi linee e sarebbe impossibile rendere giustizia anche solo a uno di loro nello spazio di un unico capitolo. L’obiettivo è offrirvi informazioni sufficienti perché possiate cominciare a fare esperienza con i microcontroller e magari scoprire qualcosa sull’ambiente di Arduino che non sapevate prima. NOTA Questo capitolo non descrive i linguaggi C o C++. Questi argomenti sono trattati in grande dettaglio altrove (trovate alcuni libri suggeriti nell’Appendice D). Qui l’intento è impartire una comprensione di come i contenuti di un programma o di uno sketch vengono convertiti in codici binari che la MCU AVR, su una scheda Arduino o ovunque si trovi, possa eseguire e che cosa è necessario per farlo succedere.
Questo capitolo inizia con una breve panoramica del cross-compiling (compilazione incrociata), la tecnica di utilizzo di un compilatore e altri strumenti su un sistema informatico per creare programmi eseguibili che possano essere trasferiti su un altro computer, magari con un’architettura completamente differente. Questo è esattamente quello che l’ambiente di sviluppo integrato di Arduino è stato progettato per fare. Il Capitolo 6 mostrerà in modo più dettagliato gli strumenti di sviluppo e le tecniche di basso livello che utilizza l’IDE di Arduino, mentre qui ci concentreremo su che cosa può fare l’IDE di Arduino e come lo si può utilizzare in modo efficace. Quindi presenteremo i bootloader, mettendo l’accento sui microcontroller AVR. Il bootloader è una funzionalità essenziale della famiglia di componenti AVR utilizzata sulle schede Arduino e capire come funziona può aiutare a ridurre la frustrazione e gettare le basi per costruire il proprio bootloader per i casi di necessità. Nel Capitolo 6 vedremo i metodi per installare un nuovo bootloader, magari progettato da voi. Quindi presenteremo l’IDE di Arduino, spiegando come si installa su vari computer host e come lo si configura per le proprie preferenze. Vedremo anche rapidamente che cosa succede dietro le quinte dell’IDE e come si è sviluppato a partire da strumenti precedenti. Un rapido sguardo a un programma semplice illustra i punti chiave nella creazione di un programma Arduino, noto come sketch.
Il capitolo procede con una panoramica del codice sorgente di Arduino e mostra dove potete trovarne una copia da esaminare. Avere a disposizione il codice sorgente, sia per le librerie fornite che per l’IDE e i suoi componenti, può aiutare a rispondere a domande come perché quello che è accaduto è accaduto così e a determinare se volete veramente provare un approccio alternativo per programmare Arduino. NOTA Ricordate che, dal momento che in questo libro l’accento è posto principalmente sull’hardware di Arduino e sui relativi moduli, sensori e componenti, il software mostrato serve soltanto a sottolineare i punti chiave e non a presentare esempi completi pronti per essere eseguiti. I codici completi dei software degli esempi e dei progetti si trovano su GitHub (https://www.github.com/ardnut).
Il cross-compiling dei microcontroller Come nel caso della maggior parte di sistemi di microcontroller a scheda singola, i programmi per Arduino e la sua MCU AVR si sviluppano su un altro sistema di un qualche tipo (Windows, Linux, oppure Mac) e poi si trasferiscono, o caricano, sul microcontroller AVR della scheda Arduino. Il sistema di sviluppo viene detto host di sviluppo e Arduino e gli altri dispositivi basati su MCU vengono detti target. Questo tipo di processo di sviluppo esiste da parecchio tempo e viene utilizzato ogni volta che è necessario creare software per una macchina di destinazione che in sé non ha la capacità di compilare il codice. La tecnica di creazione del software per un tipo di processore su un tipo di sistema diverso viene detta cross-compiling ed è davvero l’unico modo di creare software compilato per microcontroller. I microcontroller piccoli come l’AVR (o qualsiasi dispositivo piccolo da 8 bit) semplicemente non dispongono delle risorse per compilare e collegarsi a qualcosa come un programma C o C++. Quindi, per compilare e collegarsi si utilizza una macchina più capace con risorse come una CPU veloce, dischi con grande capacità e moltissima memoria e quindi il programma completo viene trasferito sul target sul quale deve essere eseguito. In alcuni casi, il sistema host può perfino disporre di un emulatore del target che gli permetta di caricare e testare i programmi in un ambiente simulato. Un emulatore potrebbe non fornire una simulazione perfetta al 100% dell’MCU target e del suo ambiente vero e proprio, ma comunque può rivelarsi uno strumento utile per verificare la funzionalità di base del software prima di caricarlo sulla MCU reale. Esistono diversi emulatori di AVR per il sistema operativo Linux, tra i quali simavr e lo GNU AVR Simulator (nell’Appendice E trovate un elenco di strumenti software per Arduino e AVR, con i relativi link).
Oggetti, immagini e codice sorgente Avrete notato che quando si parla di compilare, collegare e caricare software spesso si utilizzano i termini “oggetto”, “immagine”, “eseguibile” e “codice sorgente”. Questi sono tutti termini molto vecchi, che risalgono all’epoca delle schede perforate, delle memorie a tamburo, dei nastri magnetici e dei computer che occupavano
intere stanze. Codice sorgente, come potete intuire, si riferisce all’input che si fornisce a un compilatore o a un assembler. Il codice sorgente può essere letto dagli esseri umani e creato utilizzando un editor di testo di qualche tipo. Nel caso di Arduino di solito questo significa C o C++, creato utilizzando l’IDE di Arduino o qualche altro editor o IDE. L’output del compilatore o dell’assembler viene detto codice oggetto e in realtà non è altro che codice macchina per una determinata CPU. In altre parole, è formato dai valori binari degli operation code della CPU e degli eventuali dati associati nella forma di cosiddetti di valori letterali, anch’essi in forma binaria. Questo generalmente viene detto linguaggio macchina. Nel caso dei compilatori e degli assembler moderni, questo è quello che si trova all’interno dei file *.o e *.obj dopo il completamento dell’assemblaggio o della compilazione. Il codice oggetto può essere non immediatamente eseguibile. Se un programma è formato da due o più moduli, oppure richiede del codice oggetto proveniente da una libreria esterna, l’output del compilatore o dell’assembler conterrà segnaposti che si riferiscono al software esterno. In alcuni casi il codice esterno può trovarsi nella forma di codice sorgente (come nel caso della maggior parte del codice fornito da Arduino) e verrà compilato contemporaneamente allo sketch, oppure potrebbe essere già compilato in una libreria di oggetti che contenga uno o più moduli di codice separati. Le librerie di oggetti precompilate di solito hanno estensione *.a. Per riempire i vuoti e collegare le varie parti in un’immagine eseguibile si utilizza uno strumento detto linker. Nel caso dei programmi di Arduino, di solito questo implica l’inclusione del supporto del runtime nella forma della funzione main() e delle funzioni della libreria di runtime AVR di base per l’input/output e altre operazioni di basso livello. Il risultato finale è un’immagine eseguibile con tutto quello di cui ha bisogno il programma per girare, tutto in un unico pacchetto. Dopo la conversione in un file ASCII formato da stringhe di caratteri esadecimali, viene caricata nella MCU AVR, riconvertita in binario e salvata nella memoria flash integrata nella scheda per essere eseguita.
I bootloader Passare un programma in un microcontroller moderno può comportare uno di diversi metodi, ma il più facile è lasciare che sia la MCU ad assistere nel processo. Questo si ottiene con un piccolo bit di firmware precaricato detto bootloader (trovate una breve descrizione del firmware nel riquadro “Le origini del firmware” a pagina 96). Nella memoria flash integrata sulla scheda, la famiglia di microcontroller AVR riserva uno spazio per il bootloader. Una volta che la MCU è stata configurata in modo che utilizzi il bootloader, l’indirizzo di questo spazio di memoria speciale è il primo posto dove la MCU AVR cercherà le istruzioni quando viene accesa (o riavviata). Finché il bootloader non viene sovrascritto con un programma caricato, persiste nella memoria tra i vari cicli di accensione e spegnimento. Riservare una pozione per il bootloader in genere richiede l’attivazione di un interruttore interno, o fuse, con un dispositivo di programmazione speciale che comunica con la MCU per mezzo di un’interfaccia ICSP o JTAG. La MCU esamina la configurazione del fuse (bit di configurazione non volatile) all’avvio per determinare come è organizzata la memoria flash e se c’è dello spazio riservato per qualche tipo di bootloader o di altro codice di avvio (trovate maggiori dettagli sui fuse bit utilizzati nell’AVR in “I fuse bit” a pagina 62). Una funzionalità chiave dei dispositivi AVR è la loro capacità di caricare il codice dei
programmi nella loro memoria flash interna per mezzo di un bootloader e di un’interfaccia seriale. Nel caso dell’ATmega32U4 (descritto nei Capitoli 2 e 3), per caricare il codice del programma nella MCU può essere utilizzata l’interfaccia USB, senza bisogno di speciali dispositivi di programmazione o di MCU ausiliarie. Le schede Arduino (sia i prodotti ufficiali che le schede compatibili con il software) hanno già precaricato un bootloader di tipo Arduino nella MCU. Il bootloader di Arduino implementa un protocollo specifico che gli permette di riconoscere l’IDE di Arduino e di eseguire il trasferimento dei dati di un programma dall’host di sviluppo alla scheda target. Il bootloader di Arduino è descritto nel dettaglio in “L’azione del bootloader” a pagina 157 e alcune tecniche per sostituire il bootloader con uno di vostra scelta sono spiegate in “Sostituire il bootloader” a pagina 159.
Le origini del firmware Il termine firmware risale ai tempi nei quali i computer presentavano precaricati programmi che non potevano essere modificati sul campo. In alcuni casi, un microcontroller o un microprocessore poteva essere prodotto con software già incorporato nel suo chip di silicio. Lo sviluppatore forniva al produttore del chip il codice macchina binario, che quindi veniva incorporato nel processo di creazione del chip di silicio vero e proprio. Questa veniva detta mask programming e, per quanto permettesse di produrre componenti a basso prezzo (se venivano acquistati in quantità sufficientemente grandi), non era il modo più pratico di sviluppare software. Generalmente richiedeva una certa quantità di attrezzature di supporto per lo sviluppo, oltre a versioni speciali del microcontroller target. In alcuni casi, questo significava utilizzare un ICE (in-circuit emulator), che essenzialmente era l’equivalente funzionale del processore target, implementato utilizzando IC logici e discreti contenuti in una scatola metallica con un cavo a nastro da inserire nella presa dove il processore alla fine doveva essere collocato sul circuito. Una volta che il codice funzionava correttamente ed era stato accuratamente testato, poteva essere implementato sul chip con un certo grado di sicurezza, cioè, dando per scontato che l’ICE rappresentasse una simulazione accurata del microprocessore o del microcontroller vero e proprio. Nel caso di alcune delle prime versioni degli strumenti, questo non accadeva sempre. In altri casi, il firmware poteva essere caricato su un chip utilizzando un dispositivo di programmazione one-shot simile a quello utilizzato per programmare una chip di memoria ROM (read-only memory). In effetti, questi dispositivi di programmazione di solito potevano gestire sia dispositivi ROM che MCU. Il programma veniva salvato sul chip nella forma di bit di memoria che potevano essere impostati soltanto una volta per rappresentare valori pari a uno oppure a zero. Questi erano noti come componenti OTP, (one-time programmable). Un componente one-time programmable serviva soltanto a questo: una volta che veniva programmato restava così. Se le quantità di produzione di chip previste non riuscivano a giustificare lo sviluppo e i costi di configurazione di questo approccio, l’OTP rappresentava un’alternativa ragionevole. In ambienti di produzione piccoli, non era raro utilizzare dispositivi detti gang programmer con speciali file di socket per programmare diversi processori OTP contemporaneamente. Tuttavia, l’OTP richiedeva comunque moltissimo sviluppo up-front e molti test da eseguire con strumenti speciali. Anche se caricare su un OTP un firmware pieno di bug dal punto di vista economico non era disastroso come ordinare una produzione di 10.000 componenti difettosi, non era comunque una buona notizia quando i componenti OTP finivano nella spazzatura, a causa di un piccolo errore nel codice. Man mano che la tecnologia avanzava, i dispositivi più recenti hanno cominciato a incorporare UV-EPROM (UVerasable programmable read-only memory, che di solito si trovava nei componenti in un package DIP, o dual inline pin, con una finestra di vetro trasparente perché la luce UV toccasse il chip e resettasse i bit di memoria) ed EEPROM (electrically erasable programmable read-only memory). Entrambi questi tipi di componenti richiedevano strumenti speciali per cancellare i contenuti della memoria a sola lettura e caricare nuovi dati, ma caricare del codice sbagliato significava soltanto dover eseguire di nuovo il ciclo cancella-carica-testa-brontola, anziché buttare il dispositivo nella spazzatura. Adesso, la maggior parte delle ultime generazioni di microcontroller utilizzano memoria flash, ma si trovano ancora componenti OTP. Uno dei principali vantaggi offerti dalla memoria flash è che è a lettura/scrittura: può essere scritta così come letta, mentre il processore è attivo. Un altro grande vantaggio è che è non volatile, che
significa che i contenuti persistono tra un ciclo di alimentazione e l’altro. Il concetto di firmware basato sulla memoria non volatile a sola lettura che richiedeva strumenti speciali per essere modificata sta diventando una storia del passato, ma qualunque cosa caricata nella memoria flash di un microcontroller viene ancora detta firmware.
L’ambiente IDE di Arduino Mentre stavo scrivendo questo libro, la versione più recente dell’IDE di Arduino era la 1.6.4. Ha un aspetto simile su tutte le piattaforme. La Figura 5-1 mostra la schermata iniziale che appare quando si lancia l’IDE.
Figura 5-1 - La schermata principale dell’IDE di Arduino.
L’ultima versione dell’IDE incorpora alcune correzioni e alcuni aggiornamenti ad alcuni dei menu, aggiunge un’interfaccia a linea di comando per gestire schede e librerie e risolve alcuni problemi evidenti del codice. È stato aggiunto il supporto della nuova scheda Gemma e anche quello di schede non Arduino (cioè, non ufficiali), permettendo di inserire un URL che consenta all’IDE di ricavare informazioni su una scheda dal sito web del suo distributore e integrarle nel gestore di schede dell’IDE. Se possedete una scheda Arduino più vecchia (come per esempio una Diecimila, una Duemilanove, oppure una Uno), non disporre dell’ultima versione dell’IDE in realtà non
rappresenta un grande problema. La maggior parte della gente che utilizza una versione più vecchi dell’IDE con un tipo più vecchio di scheda Arduino probabilmente non noterà nemmeno che non dispone delle ultime modifiche. Se è il vostro caso, a meno che non prevediate di lavorare con una di queste schede Arduino più nuove (come la Yún, la Zero o la Gemma), probabilmente potete evitare di procurarvi l’ultima versione dell’IDE, almeno per adesso.
Installare l’IDE di Arduino La procedura per installare l’IDE e le librerie di Arduino varia e può rivelarsi estremamente semplice o piuttosto impegnativa, a seconda della vostra piattaforma e di quanta fatica volete fare. Per quasi tutti gli utenti Linux, l’approccio più facile è scaricare un pacchetto di installazione per mezzo del gestore di pacchetti e lasciare che questo si occupi anche di installare i pacchetti di supporto necessari. Lo svantaggio, in questo caso, è che quello che è disponibile in un repository di pacchetti può non essere l’ultima versione disponibile. Il sito web principale (http://arduino.cc/) di Arduino mette a disposizione sempre l’ultima versione, ma raccogliere tutte le parti necessarie, riunirle ed eseguirle su Linux può richiedere diversi passaggi manuali. In questo senso, le cose su Windows e Mac OS X sono più facili, come vedremo nei prossimi paragrafi. Al termine dell’installazione, è una buona idea prendersi qualche minuto e guardare che cosa è stato installato sul nostro sistema. Nella directory di installazione di Arduino troveremo il codice sorgente di diversi esempi, risorse ed esempi per le librerie predefinite, file sadecimali (immagine binaria caricabile) relativi a varie versioni del bootloader e documentazione nella forma di una serie di pagine HTML, che possono essere visualizzate con un browser web oppure aperte utilizzando la voce di menu Help nell’IDE. Su Arduino.cc (http://www.arduino.cc/en/Main/Software) trovate i file da scaricare per i sistemi host supportati. Basta selezionare quello più adatto a voi.
Windows Installare l’IDE di Arduino su un sistema Windows è semplicissimo. Il pacchetto di installazione, arduino-1.6.4-windows.exe, si occupa di tutti i dettagli. Se per caso avete una versione più vecchia dell’IDE già installata, la elimina automaticamente prima di installare quella nuova (ma senza cancellare gli sketch esistenti). I file eseguibili e le librerie di Arduino vengono collocati in Program Files\Arduino. Qui trovate anche gli esempli. Nella vostra directory home viene creata una cartella di nome Arduino, che è dove saranno salvati tutti gli sketch creati dall’utente e le librerie da lui fornite.
Linux Quasi tutte le distribuzioni Linux forniscono l’IDE di Arduino in forme preimpacchettate, che siano deb, rpm, ymp o altri tipi di pacchetti. Questo è il modo migliore di ottenere
l’IDE e le librerie in modo rapido e di installarli correttamente su un sistema Linux. Come abbiamo detto prima, lo svantaggio di questo approccio è che chi mantiene i pacchetti per varie distribuzioni Linux può non disporre dell’ultima versione disponibile su Arduino.cc nel formato di un pacchetto di distribuzione. Per esempio, l’ultima versione di Arduino disponibile per Kubuntu è la 1.0.4. Anche se un pacchetto di distribuzione è il modo più facile di ottenere l’IDE di Arduino installato su un sistema Linux, i vari componenti possono essere anche scaricati direttamente da Arduino.cc e installati manualmente. Nel caso di alcune distribuzioni, questa può essere l’unica opzione. Trovate maggiori informazioni sulle distribuzioni Linux supportate sul sito web di Arduino (http://bit.ly/apg-linux). L’installazione di un pacchetto su un sistema di tipo Ubuntu (Ubuntu, Kubuntu o qualsiasi altra distribuzione derivata da Ubuntu) si esegue utilizzando apt-get o uno strumento simile. Per installare il pacchetto dell’IDE, i sistemi OpenSuse utilizzano lo strumento yast e altri sistemi possono utilizzare rpm o qualche altro gestore di pacchetti. Dopo l’installazione, i vari esempi, hardware, file delle librerie e strumenti si trovano in /usr/share/arduino. Sui miei sistemi Kubuntu e Xubuntu, i miei sketch e le mie librerie personalizzate si trovano in una posizione predefinita nella mia directory home, in una sottodirectory di nome sketchbook.
Mac OS X La versione per Mac OS X dell’IDE e delle librerie di Arduino viene fornita in un file ZIP con il nome di arduino-1.6.4-macosx.zip. Secondo il sito web di Arduino, è pensata per la versione 10.7 (Lion) o successivo. Dopo aver decompresso l’archivio, si può copiare Arduino.app nella posizione più appropriata nel sistema (una possibilità è la cartella Applicazioni). Trovate ulteriori informazioni sull’installazione dell’IDE di Arduino su un sistema Mac OS X nel sito web Arduino.cc (http://www.arduino.cc/en/Guide/MacOSX).
Configurare l’IDE di Arduino È possibile configurare l’IDE per adattarla alle proprie necessità utilizzando la finestra di dialogo Preferences, che si trova sotto File→Preferences nel menu principale (sotto “Arduino” su un computer Mac). Questa finestra di dialogo permette di specificare la directory degli sketch, di indicare un editor esterno (se non vi piace quello incluso nell’IDE) e di modificare vari comportamenti dell’IDE. La Figura 5-2 mostra la finestra di dialogo Preferences di una versione più vecchia dell’IDE su un sistema Linux.
Figura 5-2 - La finestra di dialogo delle preferenze dell’IDE più vecchia.
Il file di preferenze, che la finestra di dialogo indica come /home/jmh/.arduino/preferences.txt nella Figura 5-2, contiene molte più impostazioni rispetto a quelle mostrate nella finestra di dialogo. Ma, come siamo soliti ripetere, non si deve modificare questo file mentre l’IDE è attivo. La Figura 5-3 mostra la finestra di dialogo Preferences relativa alla versione 1.6.4 dell’IDE. Presenta molte più opzioni rispetto alla versione più vecchia, ma comunque è soltanto una versione grafica del file di preferenze.
Figura 5-3 - La finestra di dialogo delle preferenze dell’IDE più recente.
Il file di preferenze è un file di dati ASCII KVP (coppia chiave/valore) che contiene le impostazioni dell’editor, la geometria iniziale dell’applicazione (la dimensione della finestra dell’IDE di Arduino), i parametri dell’interfaccia seriale (baud rate, dimensione dei dati, ecc.) e il browser da utilizzare per vedere i file di aiuto HTML forniti, tra le altre cose. Il file di preferenze contiene anche informazioni sull’ultimo sketch che è stato modificato e sull’ultima dimensione della finestra dell’IDE. Dal momento che viene modificata dinamicamente dall’IDE mentre è attivo, dovrebbe essere modificata manualmente quando l’IDE non è attivo. Nella versione più vecchia dell’IDE, questo potrebbe essere l’unico modo di modificare parametri come la dimensione del rientro (quella predefinita sono 2 spazi, ma io preferisco 4), la dimensione e il tipo di font utilizzati nell’editor (il predefinito è monospaziato con una dimensione pari a 12, ma io di solito lo imposto su 11 per poter vedere più codice nella finestra dell’editor) e l’espansione della tabulazione. Le versioni più recenti dell’IDE offrono maggiori opzioni nella finestra di dialogo Preferences, ma comunque potrebbero esserci alcuni dettagli che vorrete regolare nel file preferences.txt vero e proprio.
Eseguire il cross-compiling con l’IDE di Arduino Quello che rende speciale Arduino, e non soltanto una PCB con un AVR saldato, sono l’IDE di Arduino, il firmware di Arduino, il codice runtime, le librerie software sviluppate da Arduino.cc e naturalmente i programmi che vi aggiungete voi, gli sviluppatori. L’IDE di Arduino è un modo facile e veloce di costruire software per un chip AVR. E lo e perché nasconde in modo efficace la maggior parte di quello che succede quando il codice viene compilato, collegato e trasferito sull’AVR di destinazione. NOTA Il linguaggio di programmazione utilizzato dall’IDE di Arduino generalmente è C++, anche se può essere anche C, dal momento che la toolchain AVR-GCC li accetta entrambi. Per questo motivo, troverete C/C++ quando questo testo si riferisce a entrambi i linguaggi e C o C++ quando parla di un determinato linguaggio.
Nell’IDE vengono mostrati singoli file di codice sorgente in quelle che sono dette “schede”. È possibile passare da uno all’altro semplicemente selezionando la relativa scheda in alto nella finestra dell’editor. Quando il codice sorgente viene compilato, l’IDE passa in rassegna ciascuna scheda e crea un file oggetto per ciascuna di esse. Per costruire il codice dell’eseguibile binario per un dispositivo AVR, l’IDE di Arduino IDE utilizza il compilatore avr-gcc e i relativi strumenti (che vengono detti toolchain). Le librerie fornite da Arduino.cc mettono a disposizione funzioni per cose come ritardi di tempo, output di dati seriali e altre funzioni (vedere Capitolo 7). A volte, per indicare il fatto che Arduino utilizza un dialetto proprio di C/C++, si utilizza il termine “Arduinese”. Ma non è corretto. Il linguaggio utilizzato è C o C++ vero e proprio, con alcuni limiti su che cosa può essere fatto con il codice sorgente C++. Dovete ricordare che l’IDE di Arduino in realtà non è nient’altro che un “wrapper” intorno alla toolchain AVR-GCC (descritta in “La toolchain di AVR” a pagina 128). Nello specifico, in avr-libc non è presente il supporto degli operatori new e delete di C++, ma questi vengono forniti dal team di Arduino. Potete trovare le definizioni di Arduino in /usr/share/arduino/hardware/arduino/cores/arduino/new.h su un sistema Linux, in C:\Program Files\Arduino\hardware\arduino\avr\cores\arduino su un sistema Windows e in /Applicazioni/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino su un sistema Mac.
Istanziare oggetti di classe con new L’allocazione dinamica della memoria in un sistema integrato di solito non è considerata una buona idea. Generalmente, la memoria allocata dinamicamente viene presa dalla SRAM e la maggior parte delle MCU, compreso l’AVR, non sono dotate di moltissima SRAM. avr-libc supporta malloc(), ma non new. Tuttavia il team di Arduino hanno pensato che convenisse includerlo e quindi lo ha fatto. Notate che quando un oggetto di classe viene istanziato nel codice C++ di un AVR non viene creato nello spazio della SRAM. Gli AVR delle MCU da 8 bit sono processori ad architettura Harvard e non eseguono il codice dalla SRAM, ma soltanto dallo spazio della memoria flash. Qui la magia è che l’oggetto viene creato durante il momento della compilazione nella memoria flash e l’operatore new restituisce un puntatore all’oggetto. Come mostra l’Esempio 5-1, è possibile utilizzare new con la versione 1.0.5 o successiva dell’IDE in un file
sorgente che contiene variabili globali. Esempio 5-1 - Istanziare un oggetto globale con new.
Se lcd e ddsdev sono dichiarati come export in un file include corrispondente, come mostra l’Esempio 5-2, vi si può accedere da qualsiasi altro modulo sorgente che includa il file include globale. Esempio 5-2 - Dichiarare oggetti globali come esterni.
In alternativa, è possibile istanziare gli oggetti nei file sorgente delle variabili globali e poi assegnare specificamente i puntatori (anche qui può essere utilizzato lo stesso file include). Questo è mostrato nell’Esempio 5-3. Esempio 5-3 - Assegnare oggetti ai puntatore globali.
Un’osservazione interessante da fare è che, una volta compilati, gli oggetti che fanno parte di queste dichiarazioni hanno dimensioni di costruzione diverse, a seconda del metodo che si utilizza. L’approccio che fa uso di new produce un oggetto eseguibile che è 662 byte più grande del metodo dell’assegnazione del puntatore. Non è molto, a dire la verità, ma quando si dispone di appena 32K di memoria flash con la quale lavorare, ogni minimo bit conta. Queste porzioni di codice sono tratte dal codice sorgente del generatore di segnale presentato nel Capitolo 11.
Inoltre, i template C++ non sono disponibili e le eccezioni non sono supportate. Tuttavia sono supportate le classi, compresi costruttori e distruttori. Il codice C puro presenta alcuni limiti. Si possono utilizzare perfino malloc() e free(), con alcune precauzioni (trovate maggiori dettagli e istruzioni sul manuale utente (http://bit.ly/avr-libc-malloc) di avr-libc). Ma dovete tenere presente che dal punto di vista tecnico utilizzare l’allocazione dinamica della memoria con una MCU integrata è discutibile e può causare problemi e codice non fluido. Come dice il saggio: soltanto perché è possibile, non significa che si debba per forza
farlo. Per utilizzare la memoria dinamica con un microcontroller con memoria limitata, si deve avere un motivo molto valido. L’origine della confusione sul linguaggio che si utilizza con l’IDE di Arduino possono essere le definizioni delle macro e le funzioni predefinite che l’ambiente di Arduino utilizza per semplificare l’accesso alle varie funzioni I/O della MCU AVR. Uno sketch di Arduino può presentare un nome strano e un’estensione di file insolita (.ino) e può sembrare una versione ridotta di C, ma questo non è intenzionale. Ha perfettamente senso se pensate qual è il pubblico per cui è stato pensato Arduino: persone prive di una significativa esperienza con la programmazione (o addirittura che ne sono prive del tutto). Tuttavia, la complessità di C e molta di quella di C++ ci sono ancora, se volete utilizzarlo. Il Capitolo 6 descrive il processo di creazione di un codice eseguibile per Arduino (o per qualsiasi altra AVR MCU) utilizzando i componenti della toolchain AVR-GCC sottostante, un editor di testo e makefile.
I microcontroller non sono microprocessori È importante tenere presente che un microcontroller non è una CPU a scopo generale. Un tipico microcontroller è un dispositivo indipendente con soltanto una quantità limitata di memoria programma e pochissima RAM, ma con moltissime funzioni I/O già integrate. I microcontroller di solito vengono utilizzati per una serie limitata di operazioni specifiche, come rilevare le pressioni dei tasti su una tastiera, controllare alcuni motori, misurare temperature, oppure fornire l’“intelligenza” a progetti artistici dinamici, o tutto contemporaneamente. Con la possibile eccezione dell’ATmega2560, con la sua capacità di accedere a memoria esterna, un microcontroller AVR in realtà non è una piattaforma adatta per un word processor o un videogioco complesso. Detto questo, utenti intelligenti sono riusciti a utilizzare codice pulito ed efficiente per far fare al microcontroller AVR cose molto interessanti e complesse.
L’immagine eseguibile di Arduino Di solito, il software eseguibile di Arduino (l’immagine eseguibile descritta prima) è formato da tre componenti principali: lo sketch creato da uno sviluppatore (voi, in questo caso), le librerie che si utilizzano per accedere alle varie funzioni di un AVR e il codice runtime che contiene una funzione main() e un ciclo all’interno del quale eseguire il software dell’applicazione. Se riguardate la Figura 5-1, vedete che l’IDE si è reso utile fornendovi un modello minimo che potete riempire con il vostro proprio codice. Gli strumenti e i componenti software coinvolti nella creazione di codice eseguibile per un microcontroller AVR possono essere suddivisi in due categorie principali: gli strumenti di sviluppo e le sorgenti di compilazione runtime sull’host, e il codice binario eseguibile per il microcontroller AVR sul target. La Figura 5-4 mostra un diagramma a blocchi dei principali componenti software di Arduino e include il programma fornito dall’utente (lo sketch), per mostrare come il tutto si amalgama in un’immagine binaria eseguibile e completa.
Figura 5-4 - L’organizzazione del software di Arduino.
Il processo di creazione del software di Arduino Quando si utilizza l’IDE, nel processo di creazione di Arduino ci sono cinque passaggi principali: La preparazione della sorgente Lo sketch viene modificato leggermente dall’IDE, che aggiunge la dichiarazione #include "WProgram.h" nella versione 1.0 o successiva dell’IDE, oppure "Arduino.h" nelle versioni precedenti dell’IDE. Le schede (i file sorgente) che non hanno un’estensione vengono concatenati con lo sketch principale, cosa che produce un unico file di codice sorgente grande (le schede con le estensioni .c oppure .cpp vengono compilate separatamente). L’IDE cerca anche di creare prototipi di funzioni per tutte le funzioni che non siano
setup() e loop(), che si trovano nello sketch. Questi vengono collocati all’inizio del
file dello sketch, immediatamente dopo eventuali commenti o dichiarazioni del preprocessore (#include e #define), ma prima di qualsiasi tipo di dichiarazione. In un normale file sorgente C o C++, questi verrebbero inseriti in un file header .h per essere inclusi durante la compilazione del codice, ma l’IDE di Arduino se ne occupa automaticamente, creandoli e inserendoli dinamicamente nel file sorgente dello sketch. L’ultima parte della preparazione della sorgente comporta l’aggiunta dei contenuti del file main.cxx standard alla fine dello sketch (qui è dove viene definito main()). La compilazione Per tradurre il codice sorgente in file binari detti file oggetto, Arduino utilizza la suite di compilatori AVR-GCC. Questi non sono immediatamente eseguibili, ma per poter essere trattati dall’hardware di Arduino devono essere elaborati da uno strumento detto linker (come vedremo nel prossimo passaggio). Il compilatore AVR-GCC è una varietà del compilatore GCC di base costruito specificamente per essere utilizzato con la linea di dispositivi AVR di Atmel. Per via dei limiti imposti dall’hardware di destinazione (e in particolare della memoria), non sono supportate tutte le funzionalità di C++, ma il supporto di C è completo. Il compilatore accetta una vasta gamma di argomenti a linea di comando, detti anche switch. L’IDE di Arduino si occupa di fornire gli switch corretti al compilatore. Tra le altre cose, questi comprendono opzioni di ottimizzazione, specificare dove devono essere collocati i file include standard, opzioni specifiche per il target e livelli di messaggi di avvertimento. Il collegamento Il collegamento è il procedimento di connessione di file oggetto e moduli libreria. L’idea di base è riempire i “vuoti” che si trovavano nei file oggetto dove il codice sorgente originale si riferiva a un oggetto o a una funzione che si trova in una libreria o in un oggetto esterni, ma il compilatore non ne trovava l’indirizzo durante la compilazione del codice. Il compito del linker è rintracciare i riferimenti mancanti e scriverli nel file binario eseguibile finale, insieme al codice binario dei dati o delle funzioni cui si fa riferimento. La conversione Il file binario creato dal linker deve essere convertito in quello che viene detto Intel hex format, che è quello che si aspetta di trovare il firmware del bootloader sul dispositivo AVR. Per far questo si può utilizzare l’utility avr-objcopy, descritta nel Capitolo 6. L’upload Il passaggio finale consiste nel trasferire il file binario eseguibile e completato sull’hardware di Arduino. Per farlo si utilizza un collegamento USB (di solito) e il
firmware del bootloader del microcontroller, insieme a un’utility di nome AVRDUDE (che in realtà è un acronimo). È anche possibile caricare codice eseguibile in un dispositivo AVR direttamente per mezzo dell’interfaccia ICSP (come quando non c’è bootloader) e l’IDE di Arduino lo supporta.
Le schede degli sketch È possibile, e in realtà molto comodo, dividere uno sketch lungo in moduli di codice sorgente (cioè file) più piccoli, ciascuno con il suo proprio file include. Quando l’IDE carica uno sketch, cerca ulteriori file nella directory degli sketch. I file ausiliari possono essere privi di estensione o presentare le estensioni .c, .cpp, oppure .h. I file con estensione .c o .cpp appaiono in una scheda ma vengono compilati in file oggetto da collegare con il codice dello sketch principale. I file privi di estensione vengono inclusi nello sketch. Per poter utilizzare la scheda di un file con estensione .h, vi si deve fare riferimento per mezzo di una dichiarazione #include utilizzando le virgolette doppie (non le parentesi quadre). Se i file ausiliari sono accompagnati dai loro file include, questi devono essere tutti inclusi nello sketch principale, anche se non fanno riferimento al codice. Lo stesso vale per i moduli libreria esterni. Se un file ausiliario utilizza una classe che si trova in una libreria ma lo sketch principale no, devono fare riferimento al file include della libreria. Una tecnica che a me piace utilizzare è quella di inserire tutte le variabili globali (compresi gli oggetti di classe, come abbiamo detto prima) in un file sorgente separato. Questo permette a qualsiasi altro modulo che debba accedere alle variabili di farlo. Inoltre, rende lo sketch principale molto più facile da leggere, dal momento che potrebbe ridursi a contenere soltanto le funzioni setup() e loop(). Troverete maggiori informazioni sugli sketch multifile su arduino.cc (http://bit.ly/arduino-build-process) e nel Capitolo 11, che descrive un esempio funzionante e creato per il generatore di segnale DDS (il codice sorgente completo è disponibile su Github su https://github.com/ardnut).
L’architettura software di Arduino A prescindere da quanto grande o piccolo sia, uno sketch è sempre formato da almeno due funzioni obbligatorie: setup() e loop(). La funzione setup() viene chiamata una sola volta quando comincia lo sketch. La funzione loop() viene eseguita continuamente finché non si scollega l’alimentazione oppure la scheda Arduino viene resettata. La funzione loop() viene chiamata ripetutamente dalla funzione main() che viene fornita automaticamente dall’IDE di Arduino. Uno sketch può contenere anche ulteriori funzioni. Per esempio, lo sketch del termostato mostrato nel Capitolo 12 contiene diverse funzioni, oltre alle obbligatorie setup() e loop(). Il codice runtime della funzione principale è descritto in “Il supporto del runtime: la funzione main()” a pagina 109. Uno sketch, inoltre, all’inizio del file presenta alcune dichiarazioni che definiscono altri file da includere, le costanti dei pin I/O e altri valori e variabili globali. Potete vedere come è organizzato uno sketch tipico in “Uno sketch di esempio” a pagina 111. I paragrafi “Le
costanti” e “Le variabili globali” a pagina 114 e 115 parlano rispettivamente delle costanti e delle variabili globali. Un ciclo main() infinito, a volte detto ciclo di eventi, è un modo comune di programmare i microcontroller. Un piccolo dispositivo come un AVR non carica file di programmi dal disco e tutti i programmi in esecuzione su di esso sono progettati in modo che eseguano una determinata funzione (o una serie di funzioni) continuamente. Quindi, utilizzare il concetto di ciclo principale sempre in corso assume perfettamente senso. Dal momento che il codice del programma è salvato nella memoria flash, è pronto per essere eseguito dopo che viene acceso o resettato Arduino. Per aiutare a mettere le cose in prospettiva, la Figura 5-5 mostra come la funzione main() fornita dall’IDE di Arduino chiama le funzioni setup() e loop() che si trovano nello sketch.
Figura 5-5 - La struttura dei programmi di Arduino.
Nella Figura 5-5, viene istanziato (cioè, inizializzato) l’oggetto di classe di una libreria esterna che non si trova né in setup() né in loop(), in modo che possa rimanere a disposizione di tutte le funzioni dello sketch. Oltre a setup(), loop() e a eventuali altre funzioni dello sketch principale, possono esserci anche delle funzioni in altri file e i file addizionali di codice sorgente inclusi nello sketch vengono gestiti dall’IDE di Arduino nella forma di schede.
Notate che la scheda non è una libreria vera e propria, ma nient’altro che ulteriore codice sorgente dello sketch conservato in un file separato. Il codice utilizzato in una scheda può essere riutilizzato in altri sketch, ma, a differenza che nel caso delle librerie vere e proprie, è necessario specificare manualmente la scheda quando viene creato lo sketch, perché limitarsi a fornire una direttiva include nel file sorgente dello sketch principale non è sufficiente. Per aggiungere codice in uno sketch nella forma di una scheda, si deve utilizzare Sketch→Add File nella barra dei menu dell’IDE. Il file sorgente della scheda non deve per forza risiedere nella stessa directory del file dello sketch principale. Le librerie esterne vengono integrate con l’immagine eseguibile finale dopo la compilazione del codice dello sketch e di tutti i file delle schede. L’IDE di Arduino genera quindi le opzioni corrette del linker in base alle dichiarazioni include che si trovano all’inizio dello sketch. Trovate maggiori informazioni su come si incorporano le librerie negli sketch in “Utilizzare le librerie negli sketch” a pagina 116.
Il supporto del runtime: la funzione main() I compilatori che si utilizzano sui sistemi Linux, Windows e Mac OS X forniscono una libreria di funzioni specifica per la piattaforma detta libreria di runtime. Su un sistema basato su GCC, questa di solito si chiama libgcc.a o libgcc_s.so.1 e su Windows le librerie di runtime di solito hanno nomi come MSVCRT.DLL per C e MSVCPP.DLL per C++. La versione AVR è avr-libc, descritta nel Capitolo 6. La libreria di runtime contiene funzioni di uso comune specifiche per una determinata piattaforma. Queste possono essere operazioni matematiche, funzioni I/O di basso livello, timer di sistema, supporto di printf() e così via. Anche Arduino ha il suo ulteriore modulo di supporto del runtime, ma con una peculiarità. In sé, lo sketch di un programma non fa molto. Non ha nessuna funzione main() che lo faccia cominciare e nessun modo di essere eseguito continuamente una volta che parte. Il supporto del runtime di Arduino include la funzione main() necessaria, insieme ad altre funzioni di configurazione. Come potete vedere nell’Esempio 5-4, in realtà è molto semplice e si tratta di un design tipico per i microcontroller piccoli. Esempio 5-4 - La funzione main() di Arduino.
Le chiamate a init(), initVariant() e (se applicabile) USBDevice.attach() sono determinate al momento della compilazione in base al tipo di hardware Arduino di destinazione selezionato nell’IDE. Questo comprende i componenti principali del codice di supporto del runtime specifico per ciascun tipo di scheda Arduino. In un realtime operating system (RTOS) più grande, questo potrebbe fare parte del BSP (board support package) fornito dal rivenditore del RTOS o creato da uno sviluppatore. Ecco la descrizione delle funzioni: init()
Questa funzione, che si trova in Arduino/hardware/arduino/avr/cores/arduino/wiring.c, inizializza vari componenti periferici dell’AVR come timer, prescaling di timer/contatore, prescaling del convertitore A/D e modalità di output PWM in base al componente AVR utilizzato con una determinata scheda Arduino. initVariant()
Questa fornisce un “gancio” nella forma di una cosiddetta dichiarazione di funzione debole. Generalmente si utilizza per fornire ulteriore inizializzazione del runtime per hardware non incluso nelle definizioni e nel codice forniti in un ambiente di sviluppo Arduino standard. USBDevice.attach()
Fa riferimento al metodo attach() della classe USBDevice che si trova in Arduino/hardware/arduino/avr/cores/arduino/USBCore.cpp. Questa classe fornisce la funzionalità necessaria per comunicare con un’interfaccia USB. Per molti, quello che in realtà fanno queste funzioni di inizializzazione è irrilevante. Tuttavia, se davvero volete capire che cosa fa l’IDE di Arduino e come lo fa, vale la pena analizzare il codice sorgente di queste funzioni di supporto. Come si ottiene il codice sorgente è descritto in “Il codice sorgente di Arduino” a pagina 123. Come abbiamo spiegato in precedenza, le funzioni setup() e loop() sono fornite dal programmatore nello sketch del programma. La funzione setup() in genere si utilizza per definire determinate porte I/O e stati di partenza, inizializzare alcune parti delle funzioni periferiche dell’AVR, oppure eseguire altre operazioni una sola volta. È ampiamente opzionale e può perfino trattarsi di una funzione vuota, ma deve per forza esistere nello sketch, altrimenti il linker genera un messaggio di errore. La funzione loop() è dove avviene l’attività principale nello sketch di un programma. Come si può notare, viene chiamata ripetutamente finché non si toglie l’alimentazione alla scheda Arduino. Durante l’esecuzione di loop(), possono verificarsi degli interrupt, come in realtà accade, e alcune applicazioni possono incorporare l’interrupt di un timer o un ritardo per fare in modo che loop() si ripeta in un modo definito (anziché liberamente).
Uno sketch di esempio
Come abbiamo già visto, lo sketch di base di un programma di Arduino è formato da due parti: la funzione setup() e la funzione loop(). Dal momento che la funzione main() è fornita dall’IDE, quando lavoriamo su sketch semplici non ce ne dobbiamo preoccupare. Il semplice sketch dell’Esempio 5-5 controlla diversi input e produce un output se qualcuno degli input cambia da low a high. Potrebbe essere la base per un semplice antifurto. Esempio 5-5 - Semplice allarme anti intrusione.
La Figura 5-6 mostra come Arduino può essere collegato a interruttori esterni di porte e finestre. Il motivo per cui gli interruttori sono collegati in serie e per cui un’estremità della catena è collegata alla messa a terra è semplice: se uno dei fili che collegano gli interruttori del sensore viene tagliato, salta l’allarme.
Figura 5-6 - Un semplice allarme anti intrusione costruito con Arduino.
In un’applicazione come questa, gli interruttori dei sensori possono essere pistoncini del telaio di una finestra, relè reed azionati magneticamente, interruttori a levetta su porte scorrevoli o perfino un modulo sensore come un rilevatore di suono. L’annunciatore può essere qualsiasi cosa, da un cicalino piezo da 50 centesimi, a un relè che controlli una sirena o perfino un telefono autodialer. Per maggiori informazioni sui sensori compatibili con Arduino, vi rimandiamo al Capitolo 9. Il design design di base può essere esteso in un numero qualsiasi di direzioni interessanti, fino alla creazione di un sistema di allarme di qualità commerciale. Potete scaricare il software di questo libro da GitHub (https://www.github.com/ardnut).
Le costanti Esistono due modi di definire le costanti dei numeri dei pin I/O, di ritardi e altri valori. Il primo è utilizzare dichiarazioni #define. Il secondo è utilizzare numeri interi che siano inizializzati su qualche valore e poi mai modificati. Per esempio, una dichiarazione #define per associare al pin 2 un nome potrebbe presentarsi così:
L’approccio alternativo è creare un numero intero che contenga il valore:
Se osservate il codice Arduino dell’esempio, vedrete utilizzati entrambi gli approcci ed entrambi funzionano altrettanto bene. Anche se alcuni preferiscono evitare la dichiarazione #define, per qualche motivo, offre un compromesso con l’uso della memoria da tenere in considerazione. Il vantaggio che offrono le dichiarazioni #define, come nell’Esempio 5-5, è che producono un programma compilato di dimensioni inferiori. Con le dichiarazioni #define, la dimensione finale del programma dell’allarme anti intrusione è 1.452 byte. Se sostituiamo le dichiarazioni #define con le dichiarazioni int, diventa 1.540 byte. La differenza di 88 byte può non sembrare significativa, ma nel caso di uno sketch grande con molte definizioni I/O e costanti può diventarlo. Se, per esempio, tutto non deve superare i 30.720 byte per un ATmega328, può determinare se il programma funzionerà o meno.
Le variabili globali Una cosa che potete notare in tutti gli sketch è l’uso delle variabili globali. Queste sono molto comuni negli sketch di Arduino per un motivo molto valido: la funzione loop() viene chiamata ripetutamente da main() quando il codice dello sketch viene eseguito e se le variabili sono definite in loop() vengono cancellate e ricaricate ogni volta che viene chiamato loop(). Se loop() ha bisogno di una variabile con un valore persistente (per esempio un contatore), questa deve trovarsi al di fuori di loop() in modo che non venga cancellata e ricreata ripetutamente. Le variabili globali, inoltre, permettono a setup() di
impostare comodamente dei valori iniziali prima che loop() venga chiamato per la prima volta e così anche tutte le altre funzioni dello sketch avranno accesso alle variabili. In alcuni circoli, le variabili globali si sono guadagnate una cattiva reputazione, per via dei problemi che possono sorgere con “accoppiamenti” involontari tra diverse parti di un programma. In applicazioni grandi che si caricano da un disco, vengono eseguite e poi terminate da un utente, come un word processor, giochi e browser web, questo ha senso. Non è bello quando una parte di un’applicazione modifica una variabile globale e un’altra parte dell’applicazione causa un crash quando anch’essa modifica la stessa variabile globale. In sistemi con moltissima memoria a disposizione, l’allocazione dinamica della memoria, semaphore e lock mutex e la possibilità di distribuire puntatori per cose come strutture complesse, l’uso delle variabili globali potrebbe non essere giustificabile. Tuttavia, nel regno dei sistemi integrati, le variabili globali vengono utilizzate spesso come una forma efficiente di memoria compartita che sia visibile per tutte le funzioni del programma. Potete immaginare le variabili globali come un pannello pieno di interruttori, indicatori, manopole e quadranti, come nella cabina di pilotaggio di un aeroplano. Tutto dovrebbe andare bene finché rispettate la regola “modificata da una sola funzione, letta da molte funzioni”. Dal momento che uno sketch di Arduino non viene eseguito in parallelo con altri thread o processi, le possibilità di una collisione di accesso sono pari a zero. Gli interrupt possono rappresentare una sfida, a seconda di come sono implementati, ma anche qui i problemi potenziali si possono evitare con un po’ di previdenza.
Le librerie Le librerie fornite con l’IDE di Arduino si occupano di moltissime cose, ma non di tutto, come si può vedere nel Capitolo 7. Se nessuno ha dedicato tempo e sforzo per creare una libreria per un determinato sensore o una specifica interfaccia, dovrete fornire il codice voi stessi. Questo caso si verifica più spesso quando si lavora con sensori o shield personalizzati o non molto diffusi che richiedono funzioni speciali. Nell’IDE di Arduino, il termine “libreria” si utilizza in un modo che può sembrare fuori dalla linea alla quale eravate abituati se avete lavorato con GCC o Visual Studio in progetti grandi. Quando si costruisce software per un computer completo come un PC desktop, di solito la parola libreria si riferisce a un archivio di oggetto binario. Sui sistemi Linux e Unix questo si ottiene utilizzando gli strumenti ln, ar e ranlib. Il file binario che ne risulta è una collezione indicizzata di file oggetto (vedere “Oggetti, immagini e codice sorgente” a pagina 91) che il linker può utilizzare per riempire i vuoti e generare un programma completo. Se si tratta di una libreria dinamica, sarà caricata quando l’applicazione comincia (o addirittura durante l’esecuzione del programma) e il collegamento avrà luogo in quel momento.
Nell’IDE di Arduino, di solito le librerie esistono nella forma di codice sorgente finché non diventano necessarie in uno sketch. Quindi quello che accade in realtà quando viene compilato uno sketch è che lo sketch (ed eventuali file di schede), tutte le librerie necessarie e il codice runtime vengono compilati tutti contemporaneamente e collegati in un’unica immagine eseguibile binaria.
Utilizzare le librerie negli sketch Come abbiamo spiegato prima, quando l’IDE di Arduino incontra un’istruzione include che fa riferimento a una libreria già registrata con l’IDE, genera i passaggi di costruzione necessari e le opzioni del linker per incorporarla automaticamente. Tuttavia, perché questo funzioni, l’IDE deve essere avvertito in anticipo della necessità della libreria. Registrare una libreria con l’IDE è descritto in “Aggiungere una libreria nell’IDE di Arduino” a pagina 120. L’IDE di Arduino contiene già precaricata una selezione di librerie per operazioni e dispositivi I/O comuni. La Figura 5-7 mostra l’elenco di librerie disponibili in una versione più vecchia dell’IDE e la Figura 5-8 mostra l’elenco delle librerie e delle opzioni di gestione delle librerie nella versione più recente (1.6.4) dell’IDE.
Figura 5-7 - L’elenco delle librerie registrate su un IDE di Arduino più vecchio.
Figura 5-8 - L’elenco delle librerie registrate sull’ultima versione dell’IDE di Arduino.
L’Esempio 5-6 mostra come una libreria (in questo caso la libreria SoftwareSerial) viene incorporata in uno sketch. La prima cosa da notare è la dichiarazione include all’inizio del file dello sketch:
Grazie a questa l’IDE determina che ha bisogno di individuare una libreria di nome “SoftwareSerial” e si aspetta di trovarla nel suo elenco di moduli libreria conosciuti. Esempio 5-6 - Esempio di libreria 1.
L’oggetto SoftwareSerial viene istanziato nella riga:
Questo definisce anche i pin da usare per la funzione I/O seriale, cioè 2 e 3 (pin I/O digitali). Nella funzione setup(), viene impostato il baud rate seriale. La funzione loop() legge un valore dal pin dell’ingresso analogico A0 e poi invia il valore binario per mezzo dell’oggetto softSerial. La funzione loop() entra in pausa per 1 secondo dopo che è stato inviato ciascun valore binario. Questa tecnica può essere utilizzata per inviare e ricevere dati binari tra due schede Arduino, ma non funziona molto bene se volete ottenere un output leggibile per gli esseri umani. Per quello dovete utilizzare i metodi print() e println() nella libreria, come mostra l’Esempio 5-7. Esempio 5-7 - Esempio di libreria 2.
È anche possibile utilizzare la funzione di libreria standard printf() per inviare dati sulla porta seriale, ma printf() non viene già preattivato con le funzioni core di Arduino. Se volete imparare come attivare printf() e capire che effetto può avere sui vostri sketch, potete consultare la pagina web di Arduino dedicata a come attivare printf() negli sketch di Arduino (http://playground.arduino.cc/Main/Printf). Potete scoprire di più sul modulo libreria SoftwareSerial nell’aiuto integrato dell’IDE e nel paragrafo “Le librerie” e potete trovare il codice sorgente nelle directory della vostra installazione di Arduino. SoftwareSerial è descritto anche nel Capitolo 7.
Aggiungere una libreria nell’IDE di Arduino Le librerie aggiuntive fornite dall’utente sono la chiave per utilizzare dispositivi esterni come sensori di umidità e temperatura, moduli RF (radio frequenza) e componenti di controllo remoto a infrarossi (IR). Potete scrivere una libreria di funzioni personalizzata, oppure potete scegliere di installare del codice creato da qualcun altro. Le librerie aggiuntive di solito si trovano in una directory di nome libraries che si trova nella directory sketchbook. La serie di file che comprende la libreria aggiuntiva risiede in una sottocartella con un nome appropriato. È il nome di questa sottocartella che appare nell’elenco di librerie nell’IDE. Esistono due modi per farlo: Metodo 1, automatico Le versioni recenti dell’IDE di Arduino (1.0.5 e successiva) sono in grado di installare automaticamente il codice sorgente della libreria nella directory sketchbook (la posizione esatta dipende dal sistema operativo). Nel menu principale dell’IDE, si deve fare clic su Sketch→Import Library→Add Library e quindi selezionare la
directory o il file ZIP che contiene il codice sorgente della libreria. La versione più recente dell’IDE (1.6.4) utilizza una serie di passaggi leggermente diversa e le funzioni di gestione delle librerie sono raggruppate sotto “Include Library”. Uno dei vantaggi offerti da questo metodo (a parte la sua semplicità) è che l’IDE riconosce immediatamente la nuova libreria, senza richiedere che lo si riavvii. Inoltre, nelle versioni più recenti dell’IDE, potete scaricare e installare librerie provenienti da sorgenti esterne. Metodo 2, manuale Per installare manualmente una libreria aggiuntiva nell’IDE di Arduino sono necessari questi passaggi: – Innanzitutto, dovete chiudere l’IDE se è attivo. – Poi dovete decomprimere i file della nuova libreria in una cartella temporanea (la maggior parte delle librerie aggiuntive sono fornite nella forma di file ZIP). – Devono apparirvi almeno due file di codice sorgente: un file .c o .cpp (il programma) e un file .h (un include o file header). – Quindi dovete creare una sottocartella sotto
/sketchbook/libraries con lo stesso nome dei due file sorgente. – Infine dovete copiare tutti i contenuti della cartella temporanea nella nuova directory della libreria che avete creato nel passaggio precedente. Quando si riavvia l’IDE, la libreria appare elencata nell’elenco Sketch→Include Library. La convenzione per organizzare i contenuti di una libreria aggiuntiva è la seguente:
Notate che questo è soltanto un esempio. Per quel che ne so, non esiste (ancora) la libreria di un tracker IR per Arduino. La sottocartella della libreria deve avere lo stesso nome dei file sorgente e questa convenzione è utilizzata per tutte le directory dell’IDE di Arduino. Per esempio, nella cartella di esempio di Arduino (/usr/share/arduino/examples in un sistema Linux), le sottocartelle hanno gli stessi nomi dei file .ino. Come potete vedere nella struttura delle cartelle degli esempi, possono esserci ulteriori
sottocartelle per funzioni utility e anche ulteriori file sorgente rispetto ai due file che condividono lo stesso nome della sottocartella. Non appaiono nell’elenco delle librerie, ma il codice della libreria può accedervi quando viene compilato. Probabilmente avrete notato un file di nome keywords.txt al livello di base della struttura di cartelle delle librerie. Si tratta di un file importante, dal momento che offre all’IDE alcune definizioni su quali cose fare nel codice sorgente della libreria. Il file keywords.txt dell’ipotetica libreria del tracker IR utilizzato per il nostro esempio di struttura di cartelle si presenterebbe così:
Il formato è molto semplice. Il cancelletto (#) indica che tutto, fino alla fine di quella riga, è un commento e deve essere ignorato. Delle parole chiave speciali, elencate nella Tabella 5-1, servono a indicare il tipo di costanti letterali, classi, strutture, variabili o funzioni all’IDE. Tabella 5-1 - Le definizioni delle parole chiave per keywords.txt.
Tipo
Definizione
LITERAL1
Costanti letterali (cioè, macro)
LITERAL2
Costanti letterali (cioè, macro)
KEYWORD1
Classi, tipi di dati e parole chiave di C++
KEYWORD2
Metodi e funzioni
KEYWORD3
Strutture
Potete trovare anche ulteriori informazioni nel file keywords.txt che si trova nella directory dove sono installati i componenti runtime di Arduino sul vostro sistema. Sulla mia macchina Linux, questa è /usr/share/arduino/lib e su Windows si trova in C:\Program Files\Arduino\lib. Potete anche dare un’occhiata a quello che hanno fatto altri esaminando i loro file keywords.txt nelle sottocartelle delle librerie fornite con l’IDE. Anche se è possibile collocare librerie aggiuntive nella serie predefinita di cartelle dell’IDE di Arduino, questo approccio non è consigliato. Le librerie predefinite fornite con l’IDE possono cambiare quando si aggiorna l’IDE a una versione più recente. Le librerie e gli sketch aggiunti dall’utente non sono mai alterati da un aggiornamento. In ogni caso, un componente libreria è formato da due parti fondamentali: il modulo
sorgente (name.c oppure name.cpp) e il file include (name.h). Il codice del modulo sorgente è una serie di funzioni che comprende una semplice classe C++. La classe in sé è definita nel file header. Per utilizzare la libreria non si deve fare altro che copiarla in una cartella adatta, lanciare l’IDE di Arduino e quindi selezionare la nuove libreria nell’elenco Sketch→Import Library. L’IDE esamina quindi il file header e inserisce la dichiarazione #include nello sketch.
Creare librerie personalizzate Creare una libreria personalizzata da utilizzare con l’IDE di Arduino è facile. Non significa necessariamente che debba essere semplice, dal momento che le librerie possono essere molto complesse, ma, semplici o complicate, tutte seguono lo stesso modello di base. Nella versione ridotta di AVR di C++, il codice sorgente è scritto nella forma di una classe, a volte con una o più classi associate che aiutino ulteriormente. Se osservate il codice sorgente di alcune delle librerie elencate nel Capitolo 7, potete farvi un’idea di come è organizzato il codice sorgente delle librerie. Come abbiamo notato prima, una libreria minima è formata da almeno due file: il file sorgente .cpp e il file include .h. Il file sorgente contiene l’implementazione della classe della libreria e il file include contiene la definizione della classe, le definizioni dei tipi e le definizioni delle macro. Ricorderete dal nostro semplice esempio di struttura di cartelle che la directory che contiene i file sorgente e include della libreria deve avere lo stesso nome del file sorgente (.cpp) principale. Inoltre deve contenere i file keywords.txt e README e la cartella examples, che è sempre un tocco di classe (in particolare se volete rilasciare la vostra libreria perché possano utilizzarla altri).
Il codice sorgente di Arduino Il codice sorgente di Arduino completo contiene file sorgente sia per le schede basate su AVR che per le schede Due basate su ARM, che non sono trattate in questo libro. Il codice sorgente è disponibile su GitHub (https://github.com/arduino/Arduino.git) utilizzando l’URL e il comando git clone. Potete anche scaricare un file ZIP con l’immagine di tutti i file dal repository di GitHub (https://github.com/arduino/Arduino/archive/master.zip). Se prevedete di approfondire maggiormente Arduino senza limitarvi al suo IDE, vi conviene tenere a portata di mano il codice sorgente. Analizzare i file sorgente può aiutare a rendere le cose più chiare. Potete utilizzare uno strumento come Doxygen (http://bit.ly/doxygen-main) per creare una serie di pagine web collegate con grafica subordinata, grafica richiesta e un indice di classi, file sorgente e funzioni. Anche se la sorgente di Arduino non ha molto in termini di tag specifici per Doxygen, è comunque possibile generare documentazione utile.
Al livello più alto, la struttura di cartelle della sorgente di Arduino contiene directory per il codice sorgente di applicazione (app), moduli di costruzione (build), file specifici per l’hardware (hardware) e i moduli libreria inclusi nella distribuzione standard di Arduino (libraries). Da una prospettiva di basso livello, le cartelle hardware e libraries sono le più interessanti. Nella sottocartella hardware trovate il codice sorgente di vari bootloader, il codice di supporto del runtime (che in questa serie di file sorgente viene detto “core”) che include main.cpp e una piccola raccolta di moduli per EEPROM, I/O seriali, SPI e interfacce a due fili (nella cartella hardware/avr/arduino/libraries, che è diversa dalla directory libraries della quale parlavamo prima). Le librerie di supporto incluse nell’IDE di Arduino si trovano nella cartella libraries. Le sue sottocartelle includono codice sorgente per audio, Ethernet, schermi a cristalli liquidi, schede di memoria SD, servo motori, motori passo-passo, schermi TFT e moduli WiFi. Ci sono librerie anche per i prodotti Arduino Robot, Esplora e Yún. Molte delle sottocartelle delle librerie contengono anche sketch di programmi di esempio e alcune contengono documentazione nella forma di file di testo. Una cosa da tenere presenta quando si legge il codice sorgente di Arduino è che fa un uso massiccio di dichiarazioni #if, #ifdef, #ifndef e #define per determinare che cosa sarà incluso e compilato per un determinato tipo di scheda Arduino. Questo all’inizio può confondere e capire che cosa sta succedendo può richiedere un piccolo sforzo. Vale anche la pena notare che in alcuni casi viene utilizzata una funzione o una serie di funzioni, mentre in altri casi per uno scopo specifico viene definita una classe.
6 La vita senza l’IDE di Arduino
In realtà, l’hardware di Arduino non è niente di speciale: non è altro che una scheda sviluppata in modo molto semplice basata sui dispositivi AVR di Atmel. Sono il suo IDE e il suo firmware del bootloader a rendere più facile per i non programmatori lavorarci e far funzionare le cose. Tuttavia, è possibile dimenticarsi completamente dell’IDE di Arduino. Questo è un’applicazione comoda che si occupa di moltissimi dei dettagli più difficili del processo di costruzione del software al posto del programmatore, ma coloro che vogliono lavorare nella linea di comando utilizzando semplicemente un editor di testo possono farlo, senza dover utilizzare mai un IDE. In questo capitolo, vedremo alcuni esempi di modi alternativi per costruire programmi per Arduino e come si utilizza la toolchain AVR-GCC dalla linea di comando, senza nessun aiuto se non quello di un makefile. Vedremo anche come è possibile utilizzare il linguaggio assembly direttamente per collegare l’ultimo bit di prestazioni da una MCU AVR. Proprio come esistono diversi modi di creare codice eseguibile per Arduino, esistono diversi modi di caricare software in un AVR. In questo capitolo, vedremo alcune delle tecniche necessarie per farlo che non coinvolgono l’IDE di Arduino.
Le alternative all’IDE L’IDE di Arduino non è l’unico modo di sviluppare e caricare programmi per una MCU AVR su una scheda Arduino. Un’alternativa di programmazione per Arduino è lo strumento PlatformIO, che gira sotto Linux, Mac OS X e Windows. Si tratta di un costruttore di codice e gestore di librerie basato su Python che si esegue dalla linea di comando. Un altro strumento Python per costruire programmi per Arduino è Ino, che funziona su Linux e Mac OS, ma attualmente non è disponibile per l’ambiente Windows.
PlatformIO PlatformIO (http://platformio.org/) è uno strumento a linea di comando basato su Python che supporta oltre 100 diversi microcontroller di destinazione. È ampiamente indipendente dalla piattaforma, dal momento che per girare su Windows, Mac OS X o
Linux richiede soltanto Python 2.6 o 2.7 (vi consiglio di installare Python 2.7). Per ulteriori informazioni, potete visitare il sito web di PlatformIO. Basato sul tipo di microcontroller specificato, PlatformIO determina quali componenti della toolchain sono necessari e quindi li chiama nell’ordine corretto per completare le operazioni di compilazione, collegamento e caricamento sul target. Le schede supportate da PlatformIO comprendono la serie Trinket di Adafruit, tutte le schede AVR di Arduino, la BitWizard Raspduino (menzionata nel Capitolo 1), le schede Digispark di Digistump, la Engduino, le schede LowPowerLab Mote, la Microduino, le schede AVR Sanguino e le schede AVR di SparkFun. Sono supportati anche veri prodotti basati su ARM, come le schede che utilizzano la MCU SAM di Atmel, la MCU STM32, la LPC di NXP, la Nordic nRF51, oltre alla serie TI MSP430 e altre. Installare PlatformIO su un sistema Linux o Mac è facile. Si utilizza la linea di comando, si scarica uno script di installazione, oppure si utilizza uno strumento pip di Python. Prima può essere necessario installare lo strumento cURL per il trasferimento dei dati, ma questa è un’utility diffusa e sui sistemi Linux può essere ottenuta direttamente da un repository di pacchetti. La Figura 6-1 mostra l’output della console dopo aver scaricato e installato correttamente i pacchetti di PlatformIO.
Figura 6-1 - L’output della console dopo la corretta installazione di PlatformIO.
Una volta installato, potete scoprire quello che è possibile fare. Se digitate platformio
boards, vi appare il lungo elenco delle schede attualmente supportate.
Per mantenere tutto pulito e ordinato, PlatformIO utilizza la nozione dei progetti. Ciascun progetto comincia con un file di configurazione e due sottocartelle, src e lib. Il file di configurazione deve essere modificato prima di essere utilizzato. Si tratta di un file ASCII KVP (coppia chiave/valore) convenzionale di tipo INI. Trovate una documentazione più dettagliata nella pagina di riferimento “Project Configuration File” (http://bit.ly/platformio-pcf). Io consiglio di creare una sottocartella per i progetti di PlatformIO separata dalla directory sketchbook che utilizza l’IDE di Arduino. Nel mio caso, ho chiamato la mia platformio (una scelta non molto creativa, ma per me va bene). Per creare un nuovo progetto, dovete digitare platformio init. La Figura 6-2 mostra l’output della console quando si crea un progetto.
Figura 6-2 - Inizializzare un nuovo progetto di PlatformIO.
PlatformIO ha molte funzionalità, compresi framework predefiniti per vari tipi di schede, un gestore di librerie e la possibilità di integrarsi con un IDE o un editor di tipo IDE come quello di Arduino (oltre a Eclipse, Energia, Qt Creator, Sublime Text, Vim e Visual Studio).
Ino Ino è un semplice strumento di costruzione a linea di comando che adotta un approccio basato sui makefile per compilare per target Arduino. Come PlatformIO, è costruito utilizzando Python, ma, a differenza di PlatformIO, è pensato specificamente per essere utilizzato con schede Arduino. Ino supporta file di sketch *.ino e *.pde, oltre a sorgenti *.c e *.cpp, e dichiara di supportare tutte le schede supportate dall’IDE di Arduino. Notate che la versione attuale di Ino funziona soltanto con le piattaforme host Linux e
Mac OS X. Ino funziona con Python 2.6 o 2.7. Potete scaricare e installare Ino scaricando un file TAR compresso (http://inotool.org/#installation), clonandolo da GitHub, oppure utilizzando gli strumenti Python pip o easy_install. Per installare Ino e i suoi vari componenti, io ho utilizzato pip. Dopo l’installazione, lanciando il comando ino -h ho fatto apparire nella finestra della console l’output mostrato nella Figura 6-3.
Figura 6-3 - L’aiuto dello strumento Ino.
Ino crea e utilizza makefile, ma questi sono trasparenti per l’utente. Come PlatformIO, utilizza uno schema di progetti basato sulle directory e, quando si inizializza un progetto, Ino crea due sottocartelle: src e lib. Crea anche un modello di sketch essenziale (sketch.ino) nella directory src, proprio come fa la versione più recente dell’IDE di Arduino. Siete voi a dovervi occupare di riempire i vuoti e di fornire il resto dei file necessari. Trovare maggiori informazioni su Ino sul sito web ufficiale (http://inotool.org/); lo strumento può essere scaricato dal Python Package Index (http://bit.ly/ino-ppi).
La toolchain di AVR
Il mezzo principale per convertire un file sorgente con codice sorgente C o C++ in un oggetto binario che possa quindi essere incorporato in un programma AVR eseguibile e completo è il compilatore AVR-GCC, con la sua suite di utility. Tutti insieme vengono definiti una “toolchain”. Come abbiamo anticipato prima, il ruolo principale dell’IDE di Arduino è avvolgere una shell facile per l’utente intorno a questi strumenti e nascondere il più possibile i dettagli più complicati. Anche PlatformIO e Ino nascondono la toolchain dietro gli script Python. Ma comunque è ancora lì, nonostante tutto, e, se volete costruire il vostro codice AVR utilizzando un makefile dalla linea di comando, oppure se semplicemente volete eseguire ciascun passaggio manualmente, avete a vostra disposizione il compilatore, il linker, l’assembler e altri strumenti. NOTA Il pacchetto di installazione dell’IDE di Arduino (in qualsiasi forma funzioni per il vostro OS) si prende cura di installare al vostro posto la toolchain di AVR-GCC. Su un sistema Linux, l’IDE di Arduino richiede la toolchain di AVRGCC e i componenti a essa associati, e quindi il gestore di pacchetti li installa durante l’installazione dell’IDE di Arduino. Il motivo principale per installare la toolchain oltre a quello che viene fornito dall’IDE di Arduino è avere la possibilità di utilizzare le versioni più recenti degli strumenti. Su un sistema Windows, l’IDE di Arduino, gli strumenti e le librerie vengono collocati in una directory separata rispetto a dove qualcosa come la suite WinAVR normalmente posizionerebbe i componenti della sua toolchain, per cui se volete farlo potete avere a disposizione entrambi.
La Tabella 6-1 elenca gli strumenti di AVR che si trovano su un sistema Linux dopo aver installato il pacchetto di distribuzione di Arduino. La stessa serie di base di programmi si trova sui sistemi Windows o Apple dopo l’installazione dell’IDE di Arduino. I metodi per procurarsi e installare gli strumenti GNU AVR su vari sistemi host sono descritti in “Installare la toolchain” a pagina 131. Tabella 6-1 - Gli strumenti per il cross-compilation AVR.
Strumento
Descrizione
avr-addr2line
Converte gli indirizzi in nomi di file e numeri di riga
avr-ar
Crea archivi di codice oggetto e modifica o estrae codice
avr-as
L’assembler GNU portatile per l’AVR
avr-c++filt
Decodifica i simboli C++
avr-gcc
Il backend del compilatore GCC per fornire codice oggetto AVR
avr-g++
Il backend del compilatore G++ per produrre codice oggetto AVR
avr-ld
Il linker GNU per il codice oggetto AVR
avr-nm
Elenca i simboli inclusi dei file oggetto
avr-objcopy
Copia e traduce i file oggetto
avr-objdump
Mostra informazioni sui file oggetto
avr-ranlib
Genera un indice per un archivio di librerie
avr-readelf
Mostra informazioni sui file ELF
avr-size
Elenca le dimensioni totali e di sezioni dei file oggetto
avr-strings
Stampa stringhe di caratteri stampabili nei file binari
avr-strip
Elimina i simboli nei file oggetto AVR
AVRDUDE
Il programma driver per vari programmatori MCU AVR
Non tutti gli strumenti elencati nella Tabella 6-1 sono necessari per costruire programmi eseguibili per un chip AVR su una scheda Arduino. Con l’eccezione di AVRDUDE, sono versioni AVR di strumenti GNU esistenti, con funzionalità simile o identica. Gli strumenti importanti della toolchain, per poter ottenere qualcosa di compilato per Arduino (o qualsiasi MCU AVR), sono avr-gcc, avr-g++, avr-ar, avr-as, avr-ld, avrobjcopy, avr-ranlib e AVRDUDE. Il cuore della toolchain è il compilatore, che si chiama avr-gcc, oppure avr-g++ per le sorgenti C++. Questi sono versioni del compilatore GNU tagliate su misura per essere utilizzate con codice sorgente C o C++ e con la linea di microcontroller AVR di Atmel. Sono simili alla versione completa di gcc, con alcune delle opzioni del compilatore preimpostate per renderle più comode da utilizzare per il cross-compiling MCU AVR. Se per caso guardate nella directory dove sono stati installati i componenti della toolchain, ecco che cosa vi trovate:
Tutte queste non sono che varianti del compilatore GNU. I file avr-c++ e avr-g++ sono identici. Anche i file avr-cpp, avr-gcc e avr-gcc-4.5.3 sono identici. Se siete curiosi, potete ottenere le informazioni sulla versione digitando avr-gcc -v e avr-g++ -v. Dopo che il codice sorgente è stato compilato, il linker (avr-ld) combina tutti i moduli binari in un unico eseguibile. Prima di poter essere elaborati dal linker, i moduli sorgente devono essere già stati compilati in file oggetto. La compilazione e il collegamento non sono la fine del processo, però, dal momento che l’immagine binaria eseguibile creata dal linker deve essere convertita in un cosiddetto file Intel Hex, che contenga una rappresentazione ASCII del codice binario nella forma di caratteri esadecimali ASCII. Quindi può essere caricata sulla scheda target, dove il bootloader ritraduce gli esadecimali ASCII in valori binari e li scrive sulla memoria flash del microcontroller. Anche altri membri della toolchain GNU, come ar, ranlib, nm, ld e strip, hanno versioni AVR. La Figura 6-4 mostra un diagramma di come il compilatore, il linker, il convertitore e l’uploader lavorano tutti in sequenza per trasformare un programma in una forma compilata, collegare le funzioni necessarie dei moduli libreria e quindi trasferire il programma completato in un AVR target.
Figura 6-4 - La toolchain AVR-GCC.
I file oggetto mostrati nella Figura 6-4 possono essere il codice compilato di altri moduli del progetto, oppure possono provenire dal codice fornito con un sensore o altri accessori, oppure ancora possono essere codice di supporto del runtime AVR-GCC, come la funzione main() fornita dall’IDE di Arduino. Gli oggetti libreria mostrati possono essere librerie binarie vere e proprie come avr-libc, oppure altre librerie create con avrar e avr-ranlib, oppure ancora possono essere file oggetto creati quando una libreria in stile Arduino viene compilata prima del collegamento. NOTA Un componente non menzionato qui è la libreria di supporto del runtime AVR-GCC, avr-libc, che fornisce molte delle stesse funzioni che si trovano in una libreria C standard di runtime AVR-GCC. Include inoltre funzioni di supporto specifiche per il microcontroller AVR. avr-libc è descritta nel dettaglio in “avr-libc” a pagina 138.
Installare la toolchain Anche se i componenti della toolchain di solito vengono installati automaticamente durante l’installazione dell’IDE di Arduino utilizzando un gestore di pacchetti, l’installer
per Windows o il file ZIP per Mac OS X, se prevedete di non utilizzare l’IDE di Arduino potete installare questi componenti uno a uno. Come minimo, vi serviranno questi pacchetti (questi sono i nomi dei pacchetti Linux): •
avr-lib
•
avrdude
•
avrdude-doc
•
binutils-avr
•
gcc-avr
•
gdb-avr
Se utilizzate Windows, potete anche decidere di installare altri strumenti compatibili con Unix/ Linux come grep, fgrep, ls e diff. Questi sono già presenti sulle piattaforme Linux e Mac OS X. Anche se qui non è spiegato nel dettaglio, è possibile installare la toolchain AVR GNU su sistemi Solaris o BSD Unix (FreeBSD, per esempio) o su qualcosa di ancora più lontano dai sentieri battuti. Vi servono soltanto una buona ragione, moltissima pazienza e possibilmente una significativa quantità di capacità di lavorare con i pacchetti di codice sorgente. In generale, è molto più facile utilizzare sistemi per i quali sono disponibili pacchetti di installazione già pronti.
L’installazione su Windows Come abbiamo anticipato prima, il pacchetto di Arduino contiene già il compilatore e i programmi binutils necessari. Semplicemente installando l’IDE di Arduino, si installano i componenti della toolchain che gli servono nella stessa directory dove si trova il codice eseguibile principale dell’IDE. Atmel Corporation fornisce pacchetti di installazione binari e precompilati, la documentazione di base e il codice sorgente per gcc e binutils AVR. Potete accedere ai pacchetti di installazione e ad altre sorgenti nel sito web di Atmel (http://bit.ly/atmel-avrwin). I pacchetti di codice sorgente sono disponibili anche sul sito web (http://bit.ly/atmel-source). Un altro modo facile di installare la toolchain AVR-GCC su un sistema Windows è con il pacchetto WinAVR (http://winavr.sourceforge.net/). Lo script di installazione crea una directory (sulla mia macchina è C:\WinAVR-20100110) e gli eseguibili binari, le librerie e i file include vengono collocati qui. Trovate anche una buona raccolta di file di documentazione, sia in formato PDF che HTML, in C:\WinAVR-20100110\doc. Ma sappiate che WinAVR non è stato aggiornato circa dal 2010, per cui alcuni dei componenti della toolchain sono un po’ vecchi, ma è ancora possibile utilizzarli per la maggior parte dei progetti. La versione Atmel sembra essere più recente. Una raccolta di utility GNU precompilate per Windows si trova su GnuWin32 (http://gnuwin32.sourceforge.net/). Si tratta di una vasta raccolta di strumenti e utility di sistema, ma non include i compilatori gcc/ g++ né i pacchetti binutils. Potete scaricarli
da Atmel o WinAVR. Potete trovare altri pacchetti e tutorial su Google cercando “Windows avr binutils”. Se vi piace utilizzare l’editor/ambiente IDE Eclipse e volete provarlo per lo sviluppo software AVR, potete consultare il tutorial “AVR Eclipse Environment on Windows” su Protostack.com (http://bit.ly/protostack-eclipse).
L’installazione su Linux Sulla maggior parte dei sistemi Linux, l’installazione dei pacchetti GNU gcc, binutils e altri legati ad AVR è soltanto questione di selezionare i pacchetti utilizzando un gestore di pacchetti software. Potete avere installati contemporaneamente sia i “normali” componenti GCC della toolchain sia i componenti AVR della toolchain, dal momento che le versioni AVR del compilatore e gli strumenti binutils presentano il prefisso “avr-”. Non vi raccomando di cercare di costruire avr-gcc né nessuno degli altri membri della toolchain dalla sorgente, a meno che non abbiate un motivo davvero convincente per farlo e vi troviate davvero a vostro agio lavorando con pacchetti di codice sorgente molto grandi e complessi.
L’installazione su Mac OS X Dal momento che Mac OS X si basa su BSD Unix, molto di quello che può essere detto per Linux vale anche per Mac OS X. La brava gente di Adafruit ha creato un’utile guida (http://bit.ly/avr-osx) all’installazione della toolchain AVR GNU in ambiente Mac OS X. In questa pagina, il link del pacchetto per Mac è obsoleto, ma nel prossimo paragrafo troverete quello corretto. L’ambiente di sviluppo CrossPack di Object Development contiene tutti i componenti della toolchain necessari per sviluppare software AVR in ambiente Mac OS X e non richiede Xcode per essere compilato. Potete scaricarlo dal sito web di Object Development (http://bit.ly/crosspack-avr). Notate che questa è soltanto la toolchain: non fornisce un IDE GUI né un editor, per cui dovrete installarveli da soli. Esiste una versione dell’IDE di Eclipse per Mac OS X con la toolchain AVR e naturalmente esiste una versione dell’IDE di Arduino per la piattaforma Mac OS X.
make Nel caso di programmi piccoli, utilizzare i programmi della toolchain a linea di comando può andare bene, ma poi, quando le cose cominciano a espandersi, conviene disporre di un qualche modo di automatizzare il processo. Lo strumento adatto in un ambiente a linea di comando è make. make è un tipo di interprete ed elabora quelli che vengono chiamati makefile. Il linguaggio utilizzato da make non è un linguaggio di programmazione a scopo generale, ma piuttosto una serie di azioni, regole e definizioni di relazioni. Potete immaginarlo come una specie di script e spesso viene detto linguaggio macro dal momento che le dichiarazioni utilizzano rimpiazzi e sostituzioni per costruire comandi per altri strumenti.
make fa ben più che soltanto questo, però, poiché è anche in grado di rilevare cambiamenti nei file sorgente e di tener traccia delle dipendenze tra file sorgente (per esempio, se A dipende da B e C e B cambia, B verrà compilato di nuovo e anche A dovrà essere compilato di nuovo per incorporare questi cambiamenti). All’inizio, make è stato creato da Richard Stallman, Roland McGrath e Paul D. Smith. Molti IDE per lo sviluppo di codice a grande scala utilizzano make come “backend” per la compilazione. Anche gli strumenti PlatformIO e Ino utilizzano make, ma lo fanno in modo da nascondere quello che sta succedendo e poi dopo fanno le pulizie. Esistono anche degli strumenti che automatizzano il processo di creare input per lo strumento make e, se mai avete utilizzato lo strumento configure per costruire un pacchetto software, avete visto questo tipo di utility in azione. L’idea di base che sta dietro a make è gestire una vasta gamma di file sorgente dei programmi. Può determinare quale file sorgente è cambiato e quali altri file sorgente hanno bisogno di essere compilati di nuovo se dipendono dai file che sono cambiati. L’utility make può invocare compilatori, linker, generatori automatici di documentazione e perfino altri makefile (in situazioni dove il codice sorgente debba essere distribuito su diverse sottocartelle). make è anche in grado di riconoscere quando uno strumento come avr-gcc o avr-ld si imbatte in un errore. Un buon punto di partenza per farsi un’idea di come si utilizza make è analizzare i makefile che si trovano in progetti già esistenti. Descrivere tutte le funzionalità di make va ben oltre l’ambito di questo libro (il manuale GNU ufficiale è lungo più di 200 pagine) ed esistono molti libri che parlano di make e delle sue applicazioni nel dettaglio (vedere Appendice D). Potete scaricare il manuale utente ufficiale di make in formato PDF dal sito web di GNU (http://www.gnu.org/software/make/manual/make.pdf).
avr-gcc GCC è l’acronimo di GNU Compiler Collection. La GCC si basa sul concetto di utilizzare diversi processori frontend simbolici per linguaggi specifici e poi passare il codice intermedio che ne risulta a un backend per una determinata piattaforma target. Il compilatore avr-gcc è costruito a partire dalla sorgente GCC ed è preconfigurato per generare codice oggetto specificamente per la famiglia di microcontroller AVR. La GCC è in grado di generare codice oggetto a partire da molti tipi diversi di processori, tra i quali le CPU Intel che si trovano sui PC, le CPU SPARC RISC, la famiglia 68000 di microprocessori a grande scala, le MCU MSP430 di Texas Instruments, varie MCU basate su ARM e molti altri. avr-gcc e avr-g++ accettano numerosi argomenti a linea di comando, detti anche switch. Questi definiscono cose come ottimizzazione, modalità di compilazione, argomenti pass-through per il linker, percorsi dei file include e il processore target. Anche se esistono letteralmente centinaia di switch a linea di comando, per compilare correttamente il codice per un determinato processore target ne sono necessari soltanto alcuni.
La compilazione può richiedere fino a quattro passaggi: la pre-elaborazione, la compilazione, l’assemblaggio e il collegamento. Questi avvengono sempre in questo ordine. Il preprocessore espande tutte le dichiarazioni include (#include) caricando il testo nel file con nome nella sorgente corrente. Normalmente le dichiarazioni #include devono essere utilizzate soltanto per includere i cosiddetti file header, come stdio.h o stdlib.h, e non file sorgente (anche se questa generalmente non è considerata una buona idea, ho visto farlo). Il preprocessore, inoltre, si sbarazza di tutti i commenti e interpreta tutte le dichiarazioni condizionali del preprocessore, come #ifdef, #else ed #endif. L’output del preprocessore è un file sorgente pulito e leggero, che contiene codice sorgente puro e nient’altro. Per fermare il processo dopo che il preprocessore ha finito ed esaminare il codice sorgente ridotto, si può utilizzare lo switch -E. La GCC è fondamentalmente un traduttore per un particolare linguaggio tipo C come quello tradizionale, oppure ANSI C, C++, Objective-C o Objective-C++. L’output del compilatore è un file di linguaggio assembly intermedio. Di solito questo è l’input dell’assembler (avr-as), che a sua volta genera un file oggetto. Il file intermedio in linguaggio assembly viene eliminato dopo l’esecuzione dell’assembler. È possibile interrompere il processo appena prima che parta l’assembler ed esaminare l’output in linguaggio assembly utilizzando lo switch -S. Lo switch -c viene utilizzato per creare un file oggetto senza invocare il linker. Questo si utilizza nei makefile dove tutti i file sorgente vengono prima compilati e poi collegati in un unico passaggio. Il compilatore dispone anche di switch per ottimizzazione, avvertimenti (può generarne moltissimi) e specifica di percorsi in modo da poter rintracciare i file include. Lo switch -o specifica il nome di un’immagine eseguibile compilata: l’impostazione predefinita di solito è a.out. Per ulteriori informazioni, potete consultare le pagine del manuale di GCC, oppure potete scaricare un manuale utente in formato PDF, PostScript o HTML dalla documentazione online di GCC (https://gcc.gnu.org/onlinedocs). GCC non è una semplice utility e la quantità di opzioni disponibili è incredibile. Fortunatamente, per creare codice eseguibile che funzioni non avete bisogno di utilizzarle tutte.
binutils I binutils GNU sono una raccolta di programmi che gestisce le varie operazioni coinvolte nella conversione dell’output del compilatore in qualcosa che possa essere eseguito da un processore. La Tabella 6-2 elenca i contenuti del pacchetto binutils-avr su un sistema Linux. Questa suite di strumenti contiene tutto il necessario per assemblare, collegare, convertire ed elaborare file eseguibili binari in una forma adatta per un microcontroller AVR di destinazione. I manuali degli strumenti binutils e della maggior parte degli altri software GNU si trovano sul sito web ufficiale presso GNU Manuals Online (http://bit.ly/gnu-manuals). Tabella 6-2 - La raccolta di binutils AVR.
Strumento
Descrizione
avr-addr2line
Converte gli indirizzi in nomi di file e numeri di riga
avr-ar
Crea archivi di codice oggetto e modifica o estrae codice
avr-as
L’assembler GNU portatile per l’AVR
avr-c++filt
Decodifica i simboli C++
avr-ld
Il linker GNU per il codice oggetto AVR
avr-nm
Elenca i simboli inclusi dei file oggetto
avr-objcopy
Copia e traduce i file oggetto
avr-objdump
Mostra informazioni sui file oggetto
avr-ranlib
Genera un indice per un archivio di librerie
avr-readelf
Mostra informazioni sui file ELF
avr-size
Elenca le dimensioni totali e di sezioni dei file oggetto
avr-strings
Stampa stringhe di caratteri stampabili nei file binari
avr-strip
Elimina i simboli nei file oggetto AVR
Le utility di supporto essenziali e necessarie per costruire programmi per una MCU AVR sono avr-ar, avr-as, avr-ld, avr-objcopy e avr-ranlib, ma gli altri componenti della suite di binutils possono rendersi utili o meno a seconda del software che state sviluppando. Le applicazioni principali sono: avr-ar avr-ar si utilizza per creare archivi di codice oggetto binario oppure librerie statiche. Può essere utilizzato anche per modificare una libreria esistente o per estrarre codice da una libreria. Un file binario di libreria (di solito con estensione .a) è una raccolta di moduli di codice binario (cioè di moduli oggetto) con un indice principale (che si crea utilizzando avr-ranlib, descritto tra poco). La libreria di un codice oggetto viene detta libreria “statica” perché tutti i componenti che vengono utilizzati in un altro programma vi sono incorporati e diventano parti permanenti, o statiche, dell’oggetto eseguibile finale. Se siete curiosi, le librerie dinamiche condivise sono una cosa diversa e, dal momento che di solito non vengono utilizzate con i dispositivi AVR (né con altri microcontroller piccoli) non sono descritte in questo libro. avr-as avr-as è l’assembler GNU portatile per la famiglia di MCU AVR. Anche se spesso viene utilizzato insieme alla GCC, può essere utilizzato anche come assembler indipendente (come spiegato in “Il linguaggio assembly di AVR” a pagina 143). Per i microcontroller AVR esistono altri assembler che sono descritti anch’essi in “Il linguaggio assembly di AVR”, ma soltanto avr-as è pensato per essere utilizzato con i compilatori gcc/g++.
avr-ld avr-ld di solito è l’ultimo passaggio nel processo di creazione di un oggetto eseguibile binario. La funzione principale del linker è combinare due o più file oggetto, trovare tutti i riferimenti degli indirizzi tra di loro e ricollocare i dati secondo necessità. Quando un eseguibile è costruito a partire da diversi file oggetto, ciascuno di questi file oggetto può contenere un riferimento a una funzione o a dati che non risiedono all’interno di un particolare oggetto, ma in un altro. La versione AVR di libc, descritta qui di seguito, è un esempio di situazione di questo tipo. Per esempio, un programma può fare riferimento a qualcosa come atoi() (ASCII-to-integer), ma non includere la sorgente di atoi() al suo interno. Quando il programma viene compilato in un file oggetto (un file .o), il compilatore lascia un vuoto, per così dire, nel codice binario che si riferisce ad atoi(). Il linker si accorge di questa posizione vuota, trova l’indirizzo della funzione atoi() in una libreria (cioè, avr-libc.a), scrive l’indirizzo esterno nel codice e quindi include il codice oggetto della funzione atoi() nell’immagine eseguibile binaria finale. avr-objcopy L’utility avr-objcopy copia i contenuti di un file oggetto in un altro formato, di solito un file ASCII esadecimale in cosiddetto formato Intel, adatto per essere caricato su una MCU AVR utilizzando il bootloader di Arduino. avr-objcopy è anche in grado di generare un tipo di file ASCII esadecimale di nome S-record, che si utilizza spesso sulle MCU Motorola (Freescale). Il file in formato esadecimale Intel può presentarsi simile a questo, dove vedete le righe iniziali e finali del bootloader di Arduino per una MCU ATmega168 o ATmega328 MCU:
Al centro del codice sono state omesse molte righe, per amor di brevità, ma potete trovare il file originale e altri nella directory /usr/share/ arduino/hardware/arduino/bootloaders su un sistema Linux, oppure in C:\Program Files\Arduino\hardware\arduino\avr\bootloaders su un sistema Windows. In questo codice, ciascuna riga contiene un codice di partenza (il carattere :), un
conteggio di byte (che in tutte tranne che nelle quattro ultime righe del nostro esempio è l’esadecimale 10, o 16), la posizione nella quale deve essere scritto il codice nella memoria flash della MCU (il bootloader può alterarla se necessario), un codice tipo record, il codice vero e proprio scritto fino a 32 caratteri ASCII esadecimali (2 caratteri per byte, per 16 byte) e un checksum end-of-line. Trovate maggiori informazioni sul formato di file esadecimale Intel su Wikipedia (https://en.wikipedia.org/wiki/Intel_HEX), anche se raramente si rende necessario esaminare direttamente un file esadecimale. Per convertire un eseguibile binario in un file esadecimale, potete utilizzare objcopy:
objcopy, come quasi tutti gli strumenti GNU, sa fare molto di più e offre una vasta gamma di opzioni a linea di comando, la maggior parte delle quali non avrete mai l’occasione di utilizzare. Il manuale online di objcopy si trova su Sourceware.org (http://bit.ly/sw-objcopy). avr-ranlib avr-ranlib genera un indice per l’inclusione in un file archivio di oggetto binario. Questo aiuta ad rendere più agile il processo di collegamento, dal momento che questo è quello che utilizzerà il linker per trovare l’indirizzo di un oggetto necessario per riempire un “vuoto” in un altro file oggetto. Se l’indice non è disponibile, il linker deve analizzare il file della libreria, oggetto per oggetto, cercando la corrispondenza adatta.
avr-libc avr-libc è una versione AVR della libreria di runtime di C/C++. Insieme ad avr-gcc e ad avr-binutils, forma il cuore della toolchain GNU per microcontroller AVR. Le librerie esterne fornite con la toolchain AVR, come arv-libc, dovrebbero trovarsi in una posizione standard, che su un sistema Linux sarebbe qualcosa come /usr/lib/avr/lib/ oppure /usr/local/avr/lib, a seconda di come è stato costruito avr-gcc e di come è configurato il sistema. Ma, in realtà, le librerie esterne possono trovarsi in qualsiasi directory, purché il linker riesca a trovarle. avr-libc è un componente cruciale non fornito con avr-gcc e binutils. Si tratta di una libreria C/C++ standard che contiene gli equivalenti AVR delle stesse funzioni che si trovano in una libreria C standard (cioè libc GNU), con alcuni limiti dovuti alle funzionalità delle MCU AVR (memoria disponibile limitata, per esempio). La Tabella 6-3 elenca i file include disponibili con avr-libc. Se avete esperienza con la programmazione C o C++ su un sistema completo, la maggior parte di essi vi risulterà familiare. Tabella 6-3 - I file include più comuni forniti da avr-libc.
Nome del file
Descrizione
alloca.h
Alloca spazio dello stack frame del caller
assert.h
Testa un’espressione per un risultato falso
ctype.h
Macro di conversione dei caratteri e macro ctype
errno.h
Definisce codici di errori di sistema
inttypes.h
Conversioni di tipi numeri interi
math.h
Funzioni matematiche di base
setjmp.h
Definisce metodi goto non locali setjmp() e longjmp()
stdint.h
Definisce tipi numeri interi standard
stdio.h
Standard I/O facilities
stdlib.h
Utility generali
string.h
Operazioni sulle stringhe e utility
Alcuni dei file include forniti con avr-libc sono unici per l’AVR target e sono elencati nella Tabella 6-4. Questi file include si trovano nella directory /usr/lib/avr/include/avr (su un sistema Linux). Alcuni definiscono funzioni e costanti per cose come la gestione dell’avvio, i ritardi, l’accesso alla EEPROM, l’impostazione dei fuse e le funzioni dei pin delle porte. Altri definiscono gli interrupt e la mappatura degli I/O per tipi specifici di processore. Tabella 6-4 - I file include specifici per AVR forniti da avr-libc.
boot.h
io90pwm316.h
iom169pa.h
iom32u2.h
iomx8.h
iotn45.h
iox128a3.h
builtins.h
io90pwm3b.h
iom169p.h
iom32u4.h
iomxx0_1
iotn461a.h
iox128d3.h
common.h
io90pwm81.h
iom16a.h
iom32u6
iomxx4.h
iotn461.h
iox16a4.h
cpufunc.h
io90pwmx.h
iom16.h
iom406.h
iomxxhva.h
iotn48.h
iox16d4.h
crc16.h
io90scr10
iom16hva2.h
iom48.h
iotn10.h
iotn4.h
iox192a3.h
delay.h
ioa6289.h
iom16hva.h
iom48p.h
iotn11.h
iotn5.h
iox192d3
eeprom.h
ioat94k.h
iom16hvb.h
iom640.h
iotn12.h
iotn84a.h
iox256a3b.h
fuse.h
iocan128.h
iom16hvbrevb.h
iom644.h
iotn13a.h
iotn84.h
iox256a3.h
interrupt.h
iocan32.h
iom16m1.h
iom644p
iotn13.h
iotn85.h
iox256d3.h
io1200.h
iocan64.h
iom16u2
iom644p.h
iotn15.h
iotn861a.h
iox32a4.h
io2313.h
iocanxx.h
iom16u4.h
iom6450.h
iotn167.h
iotn861.h
iox32d4.h
io2323.h
io.h
iom2560.h
iom645.h
iotn20.h
iotn87.h
iox64a1.h
io2333.h
iom103.h
iom2561.h
iom6490.h
iotn22.h
iotn88.h
iox64a1u.h
io2343.h
iom1280.h
iom3000.h
iom649.h
iotn2313a
iotn9.h
iox64a3.h
io43u32x.h
iom1281.h
iom323.h
iom649p
iotn2313.h
iotnx4.h
iox64d3.h
io43u35x.h
iom1284p.h
iom324.h
iom64c1.h
iotn24a.h
iotnx5.h
lock.h
io4414.h
iom128.h
iom324pa.h
iom64.h
iotn24.h
iotnx61.h
parity.h
io4433.h
iom128rfa1.h
iom3250.h
iom64hve.h
iotn25.h
iousb1286.h
pgmspac
io4434.h
iom161.h
iom325.h
iom64m1.h
iotn261a.h
iousb128
portpins.h
io76c711.h
iom162.h
iom328p.h
iom8515.h
iotn261.h
iousb162.h
power.h
io8515.h
iom163.h
iom3290.h
iom8535
iotn26.h
iousb646.h
sfr_defs.h
io8534.h
iom164.h
iom329.h
iom88.h
iotn28.h
iousb647.h
signal.h
io8535.h
iom165.h
iom32c1.h
iom88pa.h
iotn40.h
iousb82.h
signature.h
io86r401
iom165p.h
iom32.h
iom88p.h
iotn4313.h
iousbxx2.h
sleep.h
io90pwm1.h
iom168.h
iom32hvb.h
iom8.h
iotn43u.h
iousbxx6
version.h
io90pwm216.h
iom168p.h
iom32hvbrevb.h
iom8hva.h
iotn44a.h
iox128a1.h
wdt.h
avr-libc include anche numerose utility e file include per la compatibilità, come mostra la Tabella 6-5. I file delay.h, crc16.h e parity.h che si trovano nella directory avr/ in realtà puntano a file include che si trovano nella directory util/, per cui se nel vostro codice includete, per esempio, , in realtà verrà utilizzato . Tabella 6-5 - File include utility e per la compatibilità forniti da avr-libc.
Nome del file
Descrizione
util/atomic.h
Blocchi di codice eseguiti atomicamente e non atomicamente
util/crc16.h
Calcoli CRC
util/delay.h
Funzioni per loop di ritardo busy-wait
util/delay_basic.h
Loop di ritardo busy-wait di base
util/parity.h
Generazione bit di parità
util/setbaud.h
Macro helper per calcoli di baud rate
util/twi.h
Definizioni maschere di bit TWI
compat/deprecated.h
Elementi obsoleti
compat/ina90.h
Compatibilità con IAR EWB 3.x
Per maggiori informazioni sull’uso di avr-libc potete consultare il manuale utente e non dimenticate di controllare i file include per vedere se presentano note riguardo alle loro applicazioni e i loro limiti. Tenete presente che cose come malloc() e printf(), anche se possono essere utilizzate con una MCU AVR, presentano dei limiti nell’ambiente con poca memoria dell’AVR. Un altro problema è la matematica, dal momento che le MCU AVR non dispongono di funzioni matematiche a virgola mobile. Supportano calcoli di numeri interi e a virgola fissa, ma i calcoli a virgola mobile devono essere eseguiti utilizzando una simulazione, che è lenta, per cui è da evitare il più possibile. La home page di avr-libc si trova su http://www.nongnu.org/avr-libc/. NOTA Una versione compressa bzip2 della documentazione utente in PDF si trova su http://bit.ly/avr-libc-manual. La documentazione di avr-libc parla anche della toolchain AVR.
Costruire programmi C o C++ a partire da zero Se volete costruire il vostro software senza utilizzare l’IDE di Arduino, il suo runtime AVR-GCC e le sue librerie standard, potete certamente farlo. Tuttavia, non sempre è facile riuscire a far funzionare qualcosa utilizzando gli strumenti di Arduino e poi continuare a riscrivere le parti che hanno bisogno di ottimizzazione o personalizzazione.
Compilare con avr-gcc o avr-g++ Quello che fanno avr-gcc o avr-g++ internamente con il codice sorgente non è qualcosa di cui normalmente dovreste preoccuparvi, ma, naturalmente, potete analizzare più nel dettagli gli strumenti GCC su GNU.org (https://gcc.gnu.org/onlinedocs/gccint). I comandi gcc e g++ in realtà fanno ben più che soltanto compilare il codice sorgente. Se utilizzate un comando come questo:
gcc compila test_src.c per l’ATmega32U4, chiama avr-ld per collegarlo al file di nome libruntime.a che si trova in ../avrlibs e quindi inserisce il risultato finale in un’immagine eseguibile binaria di nome test. Se volete semplicemente che il compilatore compili qualcosa in un file oggetto per collegarlo nel passaggio successivo, potete utilizzare lo switch -c (solo compilazione). Questo è comune nei makefile dove prima si compilano diversi file sorgente e poi li si collega in un file eseguibile (possibilmente anche con librerie esterne) come passaggio finale. Il comando per farlo è semplice:
avr-gcc supporta anche una suite di switch per cose come ottimizzazione, avvisi e percorsi alternativi per i file include (header).
Diversi file sorgente e make Quando si lavora con diversi file sorgente, l’utility make è essenziale. Potete scrivere il vostro proprio makefile (che è quello che di solito faccio io), oppure utilizzare uno strumento come arduino-mk. Questo è un makefile predefinito che incorpora la logica necessaria per costruire sketch di Arduino utilizzando i componenti della toolchain AVRGCC. Potete scaricare arduino-mk da GitHub. Per alcune piattaforme Linux è disponibile nella forma di un pacchetto da installare. Se lo installate da un gestore di pacchetti, notate che molto probabilmente inserirà il file principale, arduino-mk, nella stessa directory dove l’IDE di Arduino ha installato i suoi componenti. Il sito web principale si trova su Hardware Fun (http://bit.ly/hf-makefile) e potete scaricare un archivio ZIP da GitHub (http://bit.ly/gh-makefile). Una volta installato arduino-mk, probabilmente dovrete installare alcune ulteriori funzioni di supporto e definire alcune variabili globali dell’ambiente shell. Trovate maggiori dettagli nella documentazione sul sito web Hardware Fun. Se non avete dimestichezza con il linguaggio dei makefile, utilizzarli può richiedere una curva di apprendimento ripida, ma secondo me vale la pena, se volete andare oltre l’IDE e passare nel regno del vero sviluppo dei sistemi integrati. Non tutte le MCU hanno a disposizione un IDE e non tutti gli IDE sanno fare tutto quello che si può fare quando si ha il controllo diretto del processo di costruzione. Per creare un makefile semplice come quello che segue, possiamo riutilizzare i concetti dell’Esempio 5-5. In questo caso, stiamo fornendo la nostra propria funzione main() nel file sorgente main.cpp, l’equivalente delle funzioni setup() e loop() in alarmloop.c, delle variabili globali in globals.c e delle dichiarazioni #define nel file defs.h. Il nostro makefile si presenta così:
La directory di questo semplice progetto deve contenere, come minimo:
Semplicemente digitando make diamo inizio al processo. make cerca nella directory corrente un file di nome Makefile (notate la M maiuscola, che è obbligatorio) e se lo trova lo carica e lo elabora. Se volete potete assegnare al makefile un altro nome indicando a make che cosa cercare, come per esempio qui:
Il nostro makefile d’esempio ha diverse caratteristiche che vale la pena descrivere brevemente. Innanzitutto c’è la dichiarazione dei nomi alias, come CC, LD e SRCS. Questi vengono espansi quando vengono trovati più avanti nel file e permettono di risparmiare molte digitazioni ripetitive, oltre a eseguire sostituzioni con dichiarazioni condizionali. Un’altra cosa da notare sono le regole. In questo caso, ho utilizzato regole esplicite nella forma di:
L’action è rientrata utilizzando un carattere di tabulazione. make richiede obbligatoriamente questo come parte della sua sintassi e quindi qui dovete fare attenzione a non utilizzare spazi. Inoltre, notate che sotto una regola possono esserci
tutte le azioni che volete, purché ciascuna risieda sulla propria riga e sia preceduta da una tabulazione. Quando make valuta una regola, guarda le dipendenze per determinare che cosa è necessario per costruire il target. Nel caso di main.o, la regola specifica main.c e gli altri file include (header), che sono definiti dalla macro $(HDRS). Se il target non esiste ancora, verrà sempre costruito, ma se esiste make cercherà di vedere se qualcuna delle dipendenze è cambiata esaminando l’ora e la data dei file. Soltanto se sono avvenuti dei cambiamenti, il target verrà compilato di nuovo. Nel caso di $ (TARGET), la regola impone che, se qualcuno degli oggetti sorgente è cambiato, devono avvenire due azioni successive (collegamento e conversione dell’oggetto). Quindi, per esempio, se modificate alarmloop.c in modo che cambi qualcosa e poi eseguite make, la prima cosa che farà sarà compilare di nuovo alarmloop.c per creare un nuovo alarmloop.o. Quindi ricostruirà $(TARGET), dal momento che l’oggetto alarmloop.o adesso è cambiato. Se il file include alarmloop.h è cambiato, prima di ricostruire $(TARGET) compilerà di nuovo sia main.c sia alarmloop.c. Creare un makefile può rivelarsi abbastanza noioso, ma, una volta fatto, di solito non è necessario modificarlo molto spesso, eccetto forse per aggiungere un nuovo modulo sorgente oppure cambiare l’impostazione di uno switch del compilatore o del linker.
Il linguaggio assembly di AVR Per coloro che davvero desiderano ottenere le massime prestazioni da un dispositivo AVR, esiste la programmazione in linguaggio assembly. Che certamente non è indicata per i deboli di cuore, ma permette di assumere un controllo completo di quello che fa la MCU e di quando lo fa. In alcune situazioni, questo livello di controllo può rivelarsi necessario per ottenere le prestazioni migliori possibili con la quantità minima di memoria programma. Nel caso di alcune delle MCU AVR, come la serie ATtiny, in realtà il linguaggio assembly è l’unico modo di procedere, dal momento che un programma C o C++ può essere facilmente compilato in qualcosa che sarebbe troppo grande per adattarsi alla quantità limitata di memoria. In questo paragrafo, forniamo una panoramica molto di alto livello della programmazione in linguaggio assembly per AVR. Come abbiamo annunciato nella prefazione, questo libro non è un tutorial di programmazione, ma un manuale di riferimento sull’hardware e una guida per trovare fonti di informazioni più dettagliate. L’obiettivo di questo paragrafo è fornire un’idea generale di che cosa comporta la programmazione in linguaggio assembly, in modo che possiate decidere se è qualcosa in cui vi volete avventurare. Per fare giustizia a questo argomento ci vorrebbe un libro molto, molto più lungo. Fortunatamente, ne esistono già molti e potete scaricare moltissime informazioni utili da diversi siti web, come quelli elencati in “Le fonti del linguaggio assembly per AVR” a pagina 146.
Dal momento che il linguaggio assembly è più vicino all’hardware di qualsiasi altro linguaggio, a volte viene detto linguaggio macchina. In realtà, il linguaggio macchina è composto dai codici binari di varie istruzioni, mentre il linguaggio assembly è una forma del linguaggio macchina che può essere letta dagli umani. Il compito dell’assembler è tradurre da leggibile per gli umani a leggibile per le macchine e anche aggiungere alcune funzionalità utili come macro, nomi simbolici, inclusioni condizionali e la possibilità di fare riferimento a funzioni che si trovano in librerie esterne. In linguaggio assembly, possiamo scrivere qualcosa come MOV R6, R7, che copia i contenuti del registro R7 nel registro R6 e che verrà tradotto dall’assembler in una forma binaria (linguaggio macchina) che possa essere eseguita dalla MCU. I nomi che si utilizzano per le varie operazioni svolte dal processo della MCU vengono detti mnemonici e i parametri che seguono un mnemonico (se esistono) vengono detti operandi. Programmare in linguaggio assembly è l’arte di fornire le dettagliate istruzioni passo a passo necessarie perché una CPU possa fare qualcosa di utile. Un linguaggio come C si occupa dei dettagli, per cui il programmatore non deve decidere quali registri utilizzare e quali bit di stato controllare. Nel caso del linguaggio assembly, tra il programmatore e la logica fondamentale del processore non c’è niente e deve essere descritta perfino l’operazione più semplice.
Il modello di programmazione AVR Internamente, una MCU AVR consiste di un core AVR, di memoria flash ed EEPROM e di una suite di funzioni periferiche. Il core contiene un registro e decodificatore di istruzioni, un contatore di programma, una piccola quantità di RAM, vari bit di stato, 32 registri per scopi generali e una ALU (Arithmetic Logic Unit). La Figura 6-5 mostra come sono organizzati i vari componenti all’interno di una MCU AVR. Nel Capitolo 2 e nel Capitolo 3 trovate ulteriori dettagli sulle funzioni interne delle MCU AVR.
Figura 6-5 - Il diagramma a blocchi della CPU dell’AVR.
Le istruzioni agiscono sui registri e sulla memoria, nel senso che i dati possono essere copiati da un registro all’altro; che due registri possono essere confrontati, scambiati, sommati, sottratti, moltiplicati e divisi (per citare alcune delle operazioni possibili); e che i dati possono essere letti nella memoria flash, EEPROM, oppure RAM. Anche le funzioni periferiche sono controllate e vi si accede per mezzo dei registri, ma queste non fanno parte del core dei 32 registri per scopi generali. Le tre funzionalità principali della MCU (memoria, istruzioni e registri) sono descritte di seguito. L’organizzazione della memoria Come abbiamo menzionato nel Capitolo 2, la MCU AVR di Atmel utilizza quella che viene detta un’architettura Harvard. In un’architettura Harvard, il codice del programma viene salvato nella memoria a sola lettura (flash) e i dati che possono essere modificati (le variabili) vengono salvati in uno spazio di memoria separato (la RAM nel core dell’AVR). Altri microprocessori possono utilizzare uno schema alternativo che viene detto architettura Von Neumann, nella quale i programmi e i dati condividono lo stesso spazio di memoria.
In una MCU AVR, i registri per scopi generali e i registri I/O utilizzati dalle funzioni periferiche tecnicamente fanno parte dello spazio di memoria lettura/scrittura. La Figura 6-6 mostra come è organizzata la memoria nella MCU AVR.
Figura 6-6 - Il layout della memoria dell’AVR.
La Figura 6-6 è intenzionalmente generica. Le direttive CSEG, DSEG e ESEG dell’assembler (utilizzate dall’assembler di Atmel) si riferiscono rispettivamente al codice, ai dati e agli spazi di memoria EEPROM. Gli indirizzi più alti per gli spazi di memoria CSEG, DSEG e ESEG variano da un tipo di AVR all’altro. Notate che space alla fine dello spazio CSEG è riservato un bootloader facoltativo. L’elaborazione delle istruzioni Una MCU AVR utilizza quella che viene detta pipeline a livello singolo per ricavare, decodificare ed eseguire le istruzioni provenienti dalla memoria flash. Mentre viene eseguita un’istruzione, la successiva viene previamente estratta dalla memoria e diventa pronta per essere decodificata ed eseguita appena l’istruzione corrente è stata completata. Questa funzionalità e la natura RISC del core AVR è quello che permette a una MCU AVR di eseguire la maggior parte delle istruzioni in un unico ciclo del clock. I registri Molte delle istruzioni AVR impostano oppure cancellano bit in un registro di stato da
8 bit (SREG). Ciascun bit ha uno scopo preciso, come mostra la Tabella 6-6 e lo stato vero o falso (1 o 0) di alcuni bit viene controllato da istruzioni come BREQ (Branch if Equal) o BRNE (Branch if Not Equal) a seguito di un’istruzione CP (Compare), che può alterare i bit di stato Z, C, N, V, H e S. Tabella 6-6 - I bit di stato SREG di AVR. Bit
Simbolo
Funzione
0
C
Flag di carry
1
Z
Flag di zero
2
N
Flag negativo
3
V
Indicatore di overflow del complemento a due
4
S
Per test firmati
5
H
Flag di half carry
6
T
Transfer bit utilizzato dalle istruzioni BLD e BST
7
I
Flag per attivare/disattivare gli interrupt globali
I 32 registri per scopi generali sono organizzati come registri a 8 bit, con le tre coppie finali (26-27, 28-29 e 30-31) disponibili come registri di indice a 16 bit (indirizzo indiretto), riferiti rispettivamente ai puntatori X, Y e Z. Un numero limitato di istruzioni può agire su due registri a 8 bit come una coppia di registri a 16 bit. Il registro con il numero più basso della coppia contiene i bit meno significativi. Anche il registro meno significativo deve avere un numero pari e quindi la coppia r0:r1 è valida, ma r1:r2 no. Oltre al registro di stato, i registri per scopi generali e i registri I/O, l’AVR è dotato di un registro PC (program counter) e di un registro SP (stack pointer). Questi vengono modificati da certe istruzioni (un jump modifica il PC, per esempio) o da una chiamata di subroutine, che utilizza sia il registro PC che il registro SP. Per esempio, quando viene incontrata un’istruzione CALL il valore corrente del PC viene regolato in modo che punti all’istruzione che segue CALL, per poi essere “spinta” nello stack. Il PC viene quindi caricato con l’indirizzo iniziale della subroutine. Quando la subroutine ritorna per mezzo di un’istruzione RET, il PC salvato viene “estratto” dallo stack e il programma ritorna al punto immediatamente seguente l’istruzione CALL. Ovviamente ci sono molti altri dettagli che riguardano il funzionamento interno delle MCU AVR e del linguaggio assembly per AVR dei quali non abbiamo parlato qui. Se desiderate esplorare la programmazione in linguaggio assembly con un AVR, vi consiglio caldamente di leggere uno o due buoni libri. L’Appendice D contiene alcuni consigli e anche i link già menzionati sono molto utili.
Creare programmi in linguaggio assembly per AVR
A seconda dell’assembler, i commenti di una sola riga possono cominciare con un punto e virgola (;), il simbolo del cancelletto (#), oppure con qualche altro carattere. L’assembler GNU (avr-as) supporta i commenti di più righe che cominciano con /* e finiscono con */, come quelli che si trovano nel codice C. Trovate maggiori informazioni sulla documentazione del vostro assembler. I commenti in linguaggio assembly sono molto importanti. Immaginate, per esempio, di avere del linguaggio assembly che si presenta così:
A che cosa serve? In questo caso, è abbastanza facile vedere che tutto quello che fa è caricare il registro 16 (R16) con un valore pari a 0 o a 255 (0xFF) e poi scrivere quel valore su PORTB. I pin di PORTB si attiveranno o disattiveranno velocemente quando la MCU riesce a eseguire il ciclo. Possiamo migliorare questo e aggiungervi il resto dei bit mancanti per cose come l’origine del programma e l’inizializzazione delle porte. Ecco come si presenta il risultato:
Qui forse ho esagerato con i commenti, ma in linguaggio assembly non è infrequente trovare un commento quasi in ogni riga. Tenete presente che, per ottenere lo stesso risultato, perfino qualcosa di semplice come il diffuso programma “hello world” in linguaggio assembly richiede molte più istruzioni che in C o C++ e che alcune delle istruzioni dell’assembler possono non risultare immediatamente ovvie. La maggior parte degli assembler mette a disposizione una serie di parole chiave predefinite che vengono dette direttive. Nell’esempio precedente ne appare una: la direttiva .ORG. La Tabella 6-7 elenca alcune altre direttive utili. Queste parole chiave vengono dette direttive perché chiedono all’assembler di eseguire determinate
associazioni oppure determinate azioni. Tabella 6-7 - Le direttive dell’assembler dell’AVR.
Direttiva
Operazione
BYTE
Riserva uno o più byte come variabile
CSEG
Utilizza il segmento di codice
CSEGSIZE
Configura la dimensione della memoria del segmento di codice
DB
Definisce un byte o dei byte costanti
DEF
Definisce un nome simbolico per un registro
DEVICE
Definisce per quale dispositivo assemblare (il target)
DSEG
Utilizza il segmento di dati
DW
Definisce una parola o delle parole costanti (valori da 16 bit)
ENDM, ENDMACRO
Fine della definizione di una macro
EQU
Assegna un simbolo a un’espressione
ESEG
Utilizza il segmento EEPROM
EXIT
Esce dal file
INCLUDE
Legge e include sorgenti da un altro file
LIST
Attiva la generazione dei file di elenco
LISTMAC
Attiva l’espansione macro nel file di elenco
MACRO
Inizia la definizione di una macro
NOLIST
Disattiva la generazione dei file di elenco
ORG
Imposta l’origine del programma
SET
Assegna un simbolo a un’espressione
I frammenti di codice che seguono mostrano come possono essere utilizzate alcune delle direttive.
Le fonti del linguaggio assembly per AVR Se volete immergervi più in profondità nel linguaggio assembly per AVR, online potete trovare molte ottime fonti di informazione e utili tutorial: •
Il sito AVR Assembler (http://avr-asm.tripod.com/) offre moltissime informazioni, tutte ben organizzate in varie categorie.
•
AVRbeginners.net (http://www.avrbeginners.net/) è un sito web molto pratico con moltissimi dettagli sul funzionamento interno delle MCU AVR e alcuni esempi di linguaggio assembly.
•
Atmel offre il manuale di riferimento online AVR Assembler (http://bit.ly/avrassembler) e una descrizione dell’assembler di Atmel si trova nell’AVR Assembler User Guide (http://bit.ly/avr-assembler-guide). Non è uguale all’assembler avr-as, ma i principi generali sono simili.
•
L’assembler avr-as è descritto nella documentazione che si trova presso GNU Manuals Online (http://bit.ly/gnu-manuals) e ne offre una breve panoramica anche la documentazione di avr-libc.
•
Gerhard Schmidt ha creato un sito web (http://bit.ly/avr-overview) con moltissime informazioni utili, disponibile sia in inglese che in tedesco. Il materiale è disponibile anche nella forma di un file PDF (http://bit.ly/avr-overview-pdf).
•
Presso il sito web della Johns Hopkins University (http://bit.ly/jhu-assembler) potete scaricare un riassunto del linguaggio assembly.
Questa era soltanto la punta dell’iceberg, per così dire. Nell’Appendice D trovate alcuni libri consigliati.
Caricare codice eseguibile sull’AVR Compilare o assemblare codice in un file eseguibile è soltanto la metà del processo.
L’altra metà consiste nel caricare il codice eseguibile in una MCU AVR perché venga eseguito. Esistono diversi modi per farlo, come per mezzo del bootloader di Arduino, dell’interfaccia ICSP che si trova su molte schede Arduino (ameno, i pin importanti di solito sono disponibili) e di un’interfaccia JTAG.
La programmazione in-system La nota applicativa AVR910 (http://bit.ly/avr-insystem) di Atmel descrive l’interfaccia di programmazione utilizzata sulle MCU AVR. Questa è quella che sulle schede Arduino viene detta interfaccia ICSP. Fondamentalmente, si tratta di un’estensione dell’interfaccia SPI della MCU AVR. Questa funzione (I/O seriale) è stata mostrata come blocco funzionale separato nella Figura 6-5, dal momento che ha la capacità di comunicare direttamente con la memoria flash ed EEPROM della MCU.
La durata della memoria flash Tutte le memorie flash possono eseguire soltanto un numero limitato di operazioni di scrittura. Nei componenti moderni, di solito si tratta di un numero ampio (che può variare da un componente all’altro), che non è infrequente che corrisponda a 10.000 o più cicli. Questo potrebbe non sembrare molto, quando lo si compara con la quantità di lavoro che normalmente esegue un hard disk in un computer desktop, ma dobbiamo tenere presente che, anche se può essere visto come un tipo di ard disk lento (come una memoria USB), la memoria flash di un microcontroller non è un hard disk. La si utilizza per caricare un programma da eseguire e non per ospitare i dati di runtime AVR-GCC durante il funzionamento (di solito per questo scopo i microcontroller hanno a disposizione un po’ di RAM e qualcosa come un wafer microSD, con un’aspettativa di vita di circa 100.000 cicli di scrittura, può essere utilizzato per registrare grandi quantità di dati di runtime AVR-GCC). Quindi, anche se ricaricassimo i contenuti della memoria flash con il codice di un programma una volta al giorno, durerebbe comunque 4 o 5 anni.
La Figura 6-7 mostra il pinout del connettore ICSP principale su un Arduino Uno (R2). Sulla scheda c’è un secondo connettore ICSP, utilizzato per la MCU AVR che gestisce l’interfaccia USB. Il collegamento è lo stesso, ma in realtà non c’è motivo di utilizzarlo a meno che non si abbia bisogno di riprogrammare anche questa MCU (e magari di perdere la funzionalità USB). Notate che c’è anche un formato di connettore da 10 pin definito da Atmel, ma che non viene utilizzato sulla maggior parte delle schede di tipo Arduino. Il connettore da 10 pin ha gli stessi segnali del connettore da 6 pin e più collegamenti con la messa a terra che occupano gli altri 4 pin.
Figura 6-7 - Il connettore ICSP su un Arduino Uno R2.
In “I binutils” a pagina 135 abbiamo descritto lo strumento avr-objcopy, concentrandoci sulla conversione di un’immagine eseguibile binaria in un file ASCII esadecimale. Il motivo per convertire l’immagine binaria in un file esadecimale è la possibilità per il formato esadecimale Intel hex di definire segmenti di record, indirizzi e la fine del file e quindi di inviare i dati su un link di comunicazione che potrebbe avere problemi con dati binari puri. Per programmare la memoria flash la MCU AVR utilizza dati binari, ma se guardate la nota applicativa AVR910 potete vedere che, qualunque cosa stia facendo la programmazione, ha moltissimo controllo sul processo. Il file esadecimale viene utilizzato da un dispositivo di programmazione e non dalla MCU AVR.
Programmare con il bootloader Nel caso di una scheda Arduino, il dispositivo di programmazione è il bootloader nella memoria flash. Questo permette alla MCU di programmarsi da sola, al prezzo di perdere un po’ dello spazio della memoria flash per contenere il bootloader. In assenza del bootloader, avere a che fare con il posizionamento finale dei dati (indirizzi target), la configurazione dei bit della MCU (fuse) e altri dettagli di basso livello diventano compiti del dispositivo di programmazione (per maggiori dettagli sui fuse bit utilizzati nelle MCU AVR, potete leggere “I fuse bit” a pagina 62). È importante notare che il firmware del bootloader di Arduino utilizza i pin dell’interfaccia seriale dell’AVR (RxD e TxD rispettivamente sui pin D0 e D1), e quindi se volete collegare qualcosa come un convertitore RS-232 potete utilizzarlo per programmare l’AVR, oppure potete utilizzare un adattatore USB-seriale come il modulo di SparkFun mostrato nella Figura 6-8. Sulle schede Arduino che per l’interfaccia USB utilizzano un FTDI FT232L, un ATmega8, oppure un ATmega16U2, una rapida occhiata allo schema mostra che il chip dell’interfaccia o la MCU stanno utilizzando i pin seriali D0 e D1 attraverso resistenze da 1K e che per generare un reset della MCU AVR principale si
utilizza il segnale DTR.
Figura 6-8 - L’adattatore USB-seriale di SparkFun.
Potete sempre utilizzare i pin D0 e D1, sempre che siano isolati correttamente. Lo schema parziale della Figura 6-9 mostra come un FTDI FT232L è di solito collegato a una MCU AVR su Arduino. Notate che questo non vale per la Leonardo e altre schede dotate dell’ATmega32U4, che hanno un’interfaccia USB integrata.
Figura 6-9 - L’interfaccia USB di Arduino utilizzando un convertitore IC FTDI.
Caricare senza il bootloader Se per un programma davvero avete bisogno di utilizzare il massimo spazio a disposizione sulla memoria flash dell’AVR, oppure se non volete utilizzare i pin D0 e D1 nel modo standard di Arduino di caricare un programma, potete caricare un programma compilato direttamente utilizzando l’interfaccia ICSP. Questo approccio funziona con una MCU ATmega nuova fornita direttamente da Atmel, oltre che con una scheda Arduino. Caricare senza l’IDE di Arduino richiede un’interazione diretta con l’utility AVRDUDE (descritta in “AVRDUDE” a pagina 155). Di solito, questo coinvolge anche l’utilizzo di makefile o di qualche altra tecnica per produrre codice compilato. Se volete comodamente lasciare che sia l’IDE di Arduino a occuparsi di gran parte della compilazione, potete scegliere anche questa via. L’IDE di Arduino supporta la programmazione diretta dei dispositivi AVR permettendo di selezionare un dispositivo di programmazione in una voce di menu sotto Tools nel menu principale. Quindi si può avviare un upload utilizzando la funzione “Upload Using Programmer” che si trova nel menu File. Se avete sovrascritto il firmware del bootloader e poi decidete di tornare indietro per utilizzare il bootloader nel modo convenzionale, dovete ricaricarlo come descritto in “Sostituire il bootloader” a pagina 159. Ovviamente, se lo spazio di memoria non è un problema e il bootloader di Arduino è già stato installato, non c’è bisogno di eliminare il bootloader. L’interfaccia ICSP funziona bene con o senza il bootloader. Se scegliete di utilizzare l’interfaccia ICSP, potete
semplicemente ignorarlo. La vita senza il bootloader richiede un dispositivo di programmazione speciale. Alcuni strumenti di Atmel, come l’AVRISP MKII e il nuovo Atmel-ICE, sono ottimi standard, per via delle loro capacità e compatibilità. Purtroppo, Atmel ha smesso di produrre l’AVRISP MKII, a favore dell’Atmel-ICE, ma attualmente esistono molti dispositivi compatibili. L’AVRISP MKII non supportava JTAG. Tuttavia, dal momento che l’interfaccia ISP è essenzialmente una porta seriale SPI, per raggiungere il vostro scopo potete utilizzare una vasta gamma di dispositivi, compresa un’altra scheda Arduino (tra poco ne parleremo più approfonditamente). Alcuni dispositivi di programmazione facili da trovare sono anche l’USBtinyISP di Adafruit (Figura 6-10) e il Pocket AVR Programmer di SparkFun (Figura 6-11).
Figura 6-10 - L’USBtinyISP di Adafruit (assemblato).
Figura 6-11 - Il Pocket AVR Programmer di SparkFun.
L’USBtinyISP è un kit, ma è relativamente facile da assemblare. Trovate maggiori
informazioni sul sito web di Adafruit (http://bit.ly/usbtinyisp-avr). Il Pocket AVR Programmer viene già preassemblato e potete trovare ulteriori informazioni su SparkFun (http://bit.ly/sf-pocketavr). Inoltre, per caricare software su un AVR, si può utilizzare anche un programmatore che legga i registri, esamini la memoria e imposti i fuse bit. La possibilità di impostare fuse bit è un motivo imprescindibile per avere a portata di mano un qualche dispositivo ISP. Per ulteriori informazioni sui fuse bit, potete leggere “I fuse bit” a pagina 62.
JTAG JTAG, l’acronimo di Joint Test Action Group, è un’interfaccia di basso livello progettata per fornire l’accesso alle funzionalità di debugging incorporate in una MCU o in un altro dispositivo logico. La definizione formale si trova sul documento IEEE Standard Test Access Port and Boundary-Scan Architecture, IEEE Standard 1149.1-1990. La versione più recente di questo e altri standard si trova presso IEEE (https://standards.ieee.org/). Non tutte le MCU AVR offrono il supporto di JTAG. Per quello che posso dire basandomi sulle guide e le schede tecniche di Atmel, la serie di dispositivi XMEGA lo offre, ma i componenti della serie Mega da 8 bit (come quelli utilizzati sulle schede Arduino) no. Tuttavia, dal momento che esistono molti tipi di MCU AVR, è perfettamente possibile che alcuni componenti XMEGA non lo presentino e alcuni componenti Mega sì. Nella maggior parte dei casi, però, non avrete bisogno delle funzionalità avanzate di JTAG. È bello quando volete analizzare il codice passo a passo con un debugger, oppure esaminare al volo i contenuti dei registri, ma più spesso semplicemente controllare i pin con un oscilloscopio o un analizzatore logico vi fornirà moltissime informazioni. Per accedere alle funzioni interne di un AVR, potete utilizzare qualcosa come USBtinyISP per impostare i fuse bit interni dell’AVR oppure per caricare la EEPROM. Quindi, a meno che non abbiate un’impellente necessità di uno strumento JTAG, probabilmente potete risparmiarvi questo acquisto.
AVRDUDE Disporre di un programmatore AVR conviene, ma questo ha bisogno di qualcosa che gli fornisca i dati da caricare nella MCU AVR. Questo qualcosa si chiama AVRDUDE. AVRDUDE, o AVR Download UploaDEr, è un programma utility per caricare e scaricare codice e dati dagli spazi di memoria di una MCU AVR. La Figura 6-12 mostra l’output che AVRDUDE genera quando viene eseguito senza nessun argomento.
Figura 6-12 - L’ouput dell’aiuto di AVRDUDE.
AVRDUDE può anche programmare la memoria EEPROM della scheda e anche i fuse e lock bit. Lo strumento gira sia nella linea di comando sia in modalità interattiva. La modalità a linea di comando è utile quando si vuole incorporare AVRDUDE in uno script o in un makefile, mentre quella interattiva può essere utilizzata per curiosare nella memoria della MCU, modificare singoli byte nella EEPROM, oppure giocherellare con fuse o lock bit. AVRDUDE supporta una gamma di dispositivi di programmazione, come l’Atmel STK500, l’AVRISP e l’AVRISP MKII, bit-banger seriali e un’interfaccia porta parallela. Esiste un manuale in formato PDF (http://bit.ly/avrdude-pdf). L’IDE di Arduino utilizza AVRDUDE per gestire il processo di upload e potete vedere come si presenta la linea di comando attivando l’output dell’upload nella finestra di dialogo Preferences. Ecco come si presenta quando si carica il semplice sketch dell’allarme anti intrusione che abbiamo visto nel Capitolo 5:
Le cose più importanti da notare qui sono gli switch -p, -c, -P, -D e -U. Questi e alcuni degli altri switch disponibili sono descritti nella Tabella 6-8. Gli switch -v multipli semplicemente chiedono ad AVRDUDE di essere più prolisso possibile. Tabella 6-8 - Gli switch a linea di comando di AVRDUDE.
Switch
Funzione
Descrizione
-p
ID del processore
Identifica la parte collegata con il programmatore. Nel nostro caso, la scheda Arduino da programmare in realtà è dotata di un ATmega328p: è una Duemilanove.
-c
ID del programmatore
Specifica il programmatore da utilizzare. In questo caso, il programmatore è il bootloader di Arduino.
-C
Configurazione
Specifica il file di configurazione da utilizzare.
-P
Nome della porta
Identifica la porta alla quale è collegato il programmatore. Trattandosi di un sistema Linux, si utilizza la pseudo porta seriale su /dev/ ttyUSB.
-b
Baud rate della porta
Sovrascrive il baud rate predefinito.
-D
Cancellazione automatica
Disattiva la cancellazione automatica della flash.
-U
Upload
Specifica dell’upload.
Notate che lo switch -U nella linea di comando è formato da diverse parti. Definisce la memoria di destinazione (la flash), la modalità (scrittura) e un file sorgente che contenga la forma esadecimale dell’immagine eseguibile. La i alla fine della stringa dell’argomento specifica che la sorgente esadecimale è in formato Intel.
Utilizzare un Arduino come un ISP Caricando un programma utility su un Arduino, potete farlo diventare un ISP per un altro Arduino. Utilizzando questa tecnica, potete caricare un nuovo bootloader. Il sito web di Arduino (http://bit.ly/arduino-isp) fornisce semplici istruzioni. Essenzialmente, non è necessario altro che uno sketch fornito con l’IDE di Arduino e due schede Arduino. La Figura 6-13 mostra come sono collegate le schede. In questo caso, una Duemilanove funge da dispositivo ISP per un Uno R3. Può funzionare anche con schede che non hanno gli stessi pinout per i segnali dell’SPI, come la Leonardo, ma in questo caso sono necessarie alcune regolazioni. Trovate maggiori dettagli sulla documentazione di Arduino.
Figura 6-13 - Utilizzare un Arduino come programmatore per un altro Arduino.
L’azione del bootloader Lo scopo del bootloader è accettare un programma per l’AVR dal sistema di sviluppo host. I microcontroller installati sulle schede Arduino hanno già il bootloader preinstallato e nel caso della maggior parte delle applicazioni raramente si rende necessario eliminare o ricaricare il suo software. A meno che non si abbia un motivo irrinunciabile per provare a reclamare i pochi kilobyte di memoria (a seconda del tipo e dell’età del processore) che consuma il bootloader, l’approccio più facile è semplicemente non toccarlo e approfittare di esso. L’azione del bootloader di Arduino è simile a quella di qualsiasi altro microcontroller dotato di memoria flash. L’obiettivo principale è ottenere il programma fornito dall’utente nella memoria integrata e quindi trasferire il controllo al nuovo programma per l’esecuzione. Quando si fornisce alimentazione a un Arduino, comincia a essere eseguito il bootloader. Quindi il bootloader cerca nuovi dati di programma provenienti dall’interfaccia USB e, se non trova nulla dopo un breve lasso di tempo, viene eseguito il programma caricato nella sezione principale della memoria flash. Sulle versioni più recenti di Arduino, la ricerca dei dati in arrivo avviene anche mentre il
processore AVR sta eseguendo un programma salvato in precedenza, in modo che, quando viene rilevato il caricamento di un nuovo programma, il codice del programma esistente viene interrotto e il bootloader assume il pieno controllo del processore. Sulle schede Arduino più vecchie, per rilevare il caricamento si deve premere il pulsante di reset non appena l’IDE inizia a caricare il programma compilato. Per farlo nel momento giusto può rendersi necessario farlo diverse volte. Notate che si comportano così anche alcune schede compatibili con Arduino. Una volta che il bootloader ha determinato che i dati in arrivo rappresentano il caricamento di un programma valido, sblocca la memoria flash sulla scheda e comincia a leggere il nuovo programma e a scriverlo sulla memoria flash (ma non nella posizione dove risiede il bootloader). Una volta completato il caricamento, la memoria viene di nuovo bloccata in modo che non possa essere modificata accidentalmente e viene generato un interrupt che ridiriga il processore all’indirizzo iniziale del nuovo programma. Le versioni attuali del bootloader di Arduino possono leggere dati a 19.200 baud (19,2 Kbaud), o circa 1.900 byte al secondo. Le versioni più vecchie del bootloader percepivano dati in arrivo a 9.600 baud e se necessario potete alterare il comportamento dell’IDE di Arduino. A 19,2K, trasferire lo sketch di un programma lungo sul processore di destinazione può comunque richiedere molti secondi. Il codice sorgente del bootloader è disponibile su Arduino.cc e vale la pena leggerlo, se siete davvero curiosi di come funziona. Se lo leggete accuratamente, noterete che la sezione che manipola la memoria flash è scritta in linguaggio assembly per AVR. A questo punto, il codice è “puro” e interagisce con i registri di controllo interni del microcontroller, e l’assembly è il linguaggio ideale per queste operazioni. Inoltre, il codice sorgente del bootloader offre alcuni indizi su che cosa succede ai livelli più bassi in un microcontroller. Quando un programma viene caricato ed eseguito, dietro le quinte avvengono moltissime cose.
Sostituire il bootloader Se vi dovesse sorgere la necessità (o il desiderio) di installare un nuovo bootloader sul processore AVR di un Arduino, per programmare la memoria flash del microcontroller direttamente per mezzo della porta ICSP vi servirà un dispositivo, come quelli mostrati nelle Figure 6-10 e 6-11, oppure potete utilizzare il trucco Arduino-Arduino descritto in “Utilizzare un Arduino come un ISP” a pagina 154. In un AVR, il bootloader risiede in un’area specifica della memoria flash disponibile soltanto per questo scopo e la dimensione disponibile va da 256 byte a 4 KB, a seconda del tipo di AVR. L’IDE di Arduino supporta il caricamento del bootloader per mezzo di un dispositivo di programmazione come quello mostrato prima. Sotto Tools, nel menu principale dell’IDE, dovete selezionare il tipo di programmatore che avete, compilare il bootloader e quindi caricarlo sul microcontroller AVR. Trovate maggiori dettagli sull’aiuto integrato di Arduino e sul sito web principale di Arduino.
Riepilogo Questo capitolo ha spaziato tra diversi argomenti, dai componenti della toolchain AVR all’utility make, alla programmazione in linguaggio assembly e infine al cuore dei bootloader AVR. Anche se non utilizzerete mai gli strumenti o le tecniche descritti qui, vi conviene comunque sapere qualcosa di quello che succede dietro le quinte dell’IDE di Arduino. È utile anche farsi un’idea di com’era lavorare con i sistemi integrati prima che entrasse in scena l’IDE di Arduino. Se volete esplorare in maggiore dettaglio qualcuno degli argomenti presentati qui, vi conviene seguire i riferimenti forniti e non dimenticarvi di leggere l’Appendice D, dove troverete ulteriori fonti di informazioni. I microcontroller integrati sono componenti chiave della civiltà moderna e per ogni computer che vedete ce ne sono molti, molti di più che non potete vedere, nascosti nei telecomandi dei televisori, nei forni a microonde, negli stereo e nei riproduttori DVD, nei semafori, nelle automobili e perfino nella tastiera del computer sulla vostra scrivania. Una volta tutti questi piccoli dispositivi venivano programmati utilizzando le tecniche descritte brevemente in questo capitolo e molti di loro sono ancora programmati con questi stessi metodi oggi.
7 Le librerie di Arduino
L’IDE di Arduino contiene una raccolta di librerie che possono essere utilizzate con gli sketch dei programmi. Queste contengono funzioni per accedere a dispositivi periferici come un’interfaccia Ethernet, uno schermo a cristalli liquidi, un’interfaccia seriale convenzionale e molti altri. Notate che anche se il termine “libreria” si utilizza per descrivere codice ausiliario, i moduli in sé non sono sempre quello che potete immaginare come una libreria, nel senso di un modulo precompilato, come le librerie .a (archive) oppure .so (shared object) su Unix o Linux. In molti casi, sono soltanto file sorgente C o C++ standard (con i limiti di AVR-GCC, naturalmente), ma il risultato finale è ampiamente lo stesso. Il codice delle librerie viene compilato come necessario con il codice degli sketch in file oggetto e collegato con gli sketch (vedere Capitoli 5 e 6). In altri casi, una libreria in realtà è un oggetto binario, come i componenti forniti con la suite di librerie avr-libc. Se volete sapere da dove proviene una libreria o un modulo di codice esterno, potete consultare sia la documentazione di avr-libc che quella di Arduino. Dopo che lo sketch di un programma e tutti i moduli libreria sono stati compilati, l’utility linker trova i riferimenti degli indirizzi tra i componenti delle librerie e le funzioni fornite dall’utente e quindi unisce tutti i componenti in un’unica image eseguibile binaria. L’utility AVRDUDE utilizzata dall’IDE (descritta nel Capitolo 6) gestisce il processo di interazione con il bootloader della scheda (descritto nel Capitolo 5) per trasferire il codice binario compilato su un dispositivo AVR e salvarlo nella memoria integrata del processore. Per una panoramica del processo di sviluppo del software utilizzando l’IDE di Arduino, potete tornare al Capitolo 5. Il Capitolo 6 descrive lo sviluppo del codice utilizzando soltanto la toolchain AVR-GCC.
I componenti delle librerie L’ambiente di sviluppo di Arduino include una selezione di librerie di supporto per cose come I/O seriali per mezzo di un collegamento USB, EEPROM lettura/scrittura, I/O Ethernet, un’interfaccia LCD e il supporto di servomotori e motori passo-passo, tra le altre cose. Queste sono descritte nei prossimi paragrafi.
NOTA Per necessità, queste descrizioni sono scarne. Per maggiori dettagli ed esempi di uso potete consultare la pagina delle librerie di Arduino (http://bit.ly/arduino-libraries)oppure la documentazione fornita nella forma di file HTML con l’IDE di Arduino (le pagine dell’aiuto integrato). Tenete presente che il sito web di Arduino offre la documentazione più aggiornata delle versioni più recenti delle librerie, mentre l’aiuto integrato nell’IDE di Arduino descrive le librerie incluse in quello specifico rilascio.
Potete esaminare l’elenco delle librerie a vostra disposizione selezionando Sketch→Import Library nella barra degli strumenti dell’IDE. In questo modo, vedrete anche tutte le librerie che avete aggiunto nell’ambiente (come si aggiungono librerie è spiegato nel Capitolo 5). Le seguenti descrizioni riguardano le librerie fornite con un’installazione di base dell’IDE di Arduino (ulteriori librerie sono messe a disposizione da Arduino e presso altre fonti come i rivenditori di shield): EEPROM Supporta lettura e scrittura su archiviazione “permanente” utilizzando una EEPROM integrata dell’AVR Ethernet Utilizzata con la shield Ethernet di Arduino per il collegamento Ethernet Firmata Offre comunicazioni con applicazioni sul computer utilizzando un protocollo seriale standard GSM Utilizzata con la shield GSM per collegarsi a una rete GSM/GPRS LiquidCrystal Contiene funzioni per controllare LCD (liquid crystal display) SD Fornisce il supporto per scrivere e leggere schede SD di memoria flash Servo Una raccolta di funzioni per controllare servomotori SPI Supporta l’utilizzo del bus SPI (Serial Peripheral Interface) SoftwareSerial Implementa la comunicazione seriale sui pin digitali Stepper Una raccolta di funzioni per controllare i motori passo-passo TFT
Fornisce funzioni per disegnare testo, immagini e forme sullo schermo TFT di Arduino WiFi Supporta la shield WiFi di Arduino per le reti wireless Wire Supporta l’interfaccia a due fili (TWI/I2C) per inviare e ricevere dai su un network di dispositivi o di sensori Esplora Fornisce funzioni per accedere ai vari attuatori e sensori montati sulla scheda Esplora (si utilizza solamente sulla Esplora) USB Utilizzata con le schede Leonardo, Micro, Due e Esplora per gli I/O seriali per mezzo del collegamento USB Keyboard Invia pressioni di tasti a un computer collegato Mouse Controlla il movimento del cursore su un computer collegato
EEPROM La libreria EEPROM supporta lettura e scrittura su archiviazione “permanente” utilizzando una EEPROM integrata nell’AVR. La EEPROM è persistente e conserva tutto quello che vi è stato scritto quando viene tolta l’alimentazione dalla scheda. Anche se la memoria flash principale del microcontroller è altrettanto non volatile, la EEPROM non viene disturbata quando sulla scheda viene caricato del nuovo codice eseguibile. Vi si deve accedere specificamente via software. I diversi tipi di microcontroller AVR utilizzati sulle schede Arduino hanno diverse quantità di spazio di archiviazione EEPROM disponibile, che vanno dai 512 byte dell’ATmega168 ai 4 KB dell’ATmega1280 e dell’ATmega2560. Nel Capitolo 3 trovate i dettagli specifici per ciascun microcontroller. La classe EEPROM definisce le funzioni utilizzate per leggere, scrivere e caricare i contenuti della EEPROM integrata sull’AVR. Deve essere istanziata prima che possa essere utilizzata qualsiasi funzione della EEPROM. Il file include della libreria, EEPROM.h, dichiara EEPROM come un’istanza statica della classe EEPROM. Se volete utilizzare la classe istanziando voi stessi un oggetto EEPROM, dovete eseguire questo:
Le versioni più vecchie della libreria EEPROM dispongono di sole due funzioni per accedere alla EEPROM integrata di una MCU AVR:
read()
Legge il valore di un byte da un determinato indirizzo nella EEPROM. Le posizioni non inizializzate conterranno un valore pari a 255. Questa funzione restituisce il valore del byte letto presso l’indirizzo dato. Gli indirizzi partono da zero (0).
write()
Scrive il valore di un byte sullo spazio di archiviazione EEPROM del microcontroller presso un determinato indirizzo. Gli indirizzi partono da zero (0). Per eseguire un’operazione di scrittura sulla EEPROM ci vogliono circa 3,3 ms e la EEPROM della VR ha un’autonomia dichiarata di 100.000 cicli scrittura/lettura, quindi dovrebbe durare abbastanza. La funzione non restituisce nulla.
L’ultima versione della libreria EEPROM ha quattro ulteriori funzioni: update(), get(), put() ed EEPROM[]. Vale la pena guardare il codice sorgente della classe della libreria EEPROM per vedere come il codice gestisce i tipi di dati arbitrari. update()
La funzione update() scrive un byte di dati sulla EEPROM presso un determinato indirizzo, ma soltanto se il valore che si trova attualmente in quell’indirizzo è diverso da quello fornito come argomento alla funzione. Questa funzione non restituisce nulla.
put()
La funzione put() scrive dati di qualsiasi tipo sulla EEPROM, cominciando nell’indirizzo specificato. I dati possono essere tipi primitivi (per esempio, numeri interi o a virgola mobile), oppure possono essere strutture. La funzione restituisce un riferimento all’oggetto dei dati passato per mezzo dell’argomento data. Notate che per eseguire l’operazione di scrittura questa funzione utilizza update() e quindi la scrittura non avviene se i dati che si trovano presso l’indirizzo specificato sono uguali a quelli passati nella chiamata a put().
get()
La funzione get() legge e restituisce dati o oggetti di qualunque tipo nella EEPROM. I dati letti nella EEPROM sono scritti presso l’indirizzo dell’argomento data in stile byte-wise, con la quantità di byte corrispondente alla dimensione dell’oggetto a cui punta data. La funzione restituisce un riferimento all’oggetto dei dati passato per mezzo dell’argomento data.
EEPROM[]
L’operatore EEPROM[] permette di accedere alla EEPROM come se fosse un oggetto array. L’indirizzo vero e proprio della EEPROM è EEPROM_base_address + int index. L’operatore restituisce un riferimento alla cella della EEPROM.
Ecco un semplice esempio basato vagamente su quello che è fornito da Arduino.cc nella documentazione della libreria EEPROM, ma con qualche modifica. Scrive e legge nello spazio di memoria della EEPROM e utilizza l’operatore modulo per determinare se un valore è pari o dispari:
Ethernet La libreria Ethernet fornisce la funzionalità necessaria per interagire con una shield Ethernet di Arduino. Come nel caso di tutte le librerie di Arduino, è abbastanza complessa e offre funzionalità sia server che client. Inoltre, supporta quattro connessioni input o output (o una miscela dei due) simultanee. Per comunicare con la scheda host Arduino, la shield Ethernet utilizza l’interfaccia SPI. La libreria Ethernet è formata da una raccolta di cinque classi C++. La maggior parte delle classi eredita dalle classi genitore,
ma, nel caso della maggior parte delle applicazioni, non dovete preoccuparvi dei dettagli. Tuttavia, se avete bisogno di vedere le definizioni della classe a basso livello, potete trovarle nella directory hardware/arduino/avr/cores/arduino nel codice sorgente di Arduino. Questo elenco mostra le cinque classi della libreria Ethernet e le funzioni pubbliche di ciascuna classe. Vedremo ciascuna di esse più nel dettaglio nei prossimi paragrafi: •
Classe Ethernet
•
– begin() – localIP() – maintain() Classe IPAddress
•
Classe Server
•
– EthernetServer() – begin() – available() – write() – print() – println() Classe Client
•
– EthernetClient() – connected() – connect() – write() – print() – println() – available() – read() – flush() – stop() Classe EthernetUDP – – – – – –
begin() read() write() beginPacket() endPacket() parsePacket()
– – –
available() stop() remotePort()
La classe Ethernet: EthernetClass La classe Ethernet inizializza la libreria Ethernet e le impostazioni di rete. Il nome reale della classe è EthernetClass e un oggetto di nome Ethernet viene istanziato nel file della libreria Ethernet.cpp ed esportato in Ethernet.h. Se volete, potete creare la vostra propria istanza di EthernetClass, oppure potete utilizzare semplicemente quella che fornisce la libreria. begin()
Si utilizza per inizializzare la libreria Ethernet e stabilire i parametri della connessione di rete. Il metodo (o funzione, se preferite) begin() è overloaded e quindi esistono cinque modi di invocarlo. Tutti gli argomenti sono array di uint8_t byte. La forma soltanto DHCP di questo metodo (Ethernet.begin(mac)) restituisce 1 se si è ottenuto correttamente un lease DHCP, 0 in caso contrario. Tutte le altre forme non restituiscono niente. Il tipo di classe IPAddress è descritto nel prossimo paragrafo.
localIP()
Ottiene l’indirizzo IP del local host (per esempio, la shield Ethernet). Questo è utile per determinare l’indirizzo IP locale quando si utilizza DHCP. Se l’Ethernet locale è stato inizializzato correttamente, Ethernet.localIP() restituisce un oggetto IPAddress che contiene l’indirizzo IP assegnato o specificato.
maintain()
Questo metodo non appare nelle versioni più vecchie della libreria. Quando a un dispositivo viene assegnato un indirizzo IP da un server DHCP, viene detto lease e un lease DHCP è dato per un determinato periodo di tempo (dipende da come è stato configurato il server DHCP). Il metodo Ethernet.maintain() serve a rinnovare un lease DHCP. Ethernet.maintain() restituisce 0 se non è successo niente, 1 se il rinnovo del lease non è riuscito, 2 se il lease è stato rinnovato correttamente, 3 se il rebind DHCP non è riuscito e 4 se il rebind è riuscito.
La classe IPAddress La classe IPAddress definisce un oggetto dati che contiene i dati degli indirizzi IP locali e remoti. La classe ha quattro tipi di costruttori overloaded. Ciascuno accetta una forma diversa di indirizzo come mostrato qui:
Un oggetto IPAddress può contenere una serie di quattro ottetti di indirizzi IP (il formato 192.168.1.100, per esempio, senza i punti), una versione con un numero intero da 32 bit di un indirizzo IP, oppure un array di byte senza segno. La classe IPAddress serve a creare istanze di tipi di dati indirizzo. Per esempio:
ip, dnServer, gateway e subnet sono oggetti di tipo IPAddress. La libreria Ethernet sa
che deve cercare questi nomi quando inizializza un’interfaccia Ethernet. Notate che tutti utilizzano la forma di inizializzazione con diversi ottetti. Potete trovare il file sorgente di IPAddress nella Arduino/hardware/arduino/avr/cores/arduino della sorgente di Arduino.
directory
La classe Server: EthernetServer Nel vocabolario di Ethernet, un server e un sistema (o un host) che accetta richieste di connessione da un altro sistema e stabilisce un canale di comunicazione. Il sistema che richiede la connessione viene detto client. Un server aspetta passivamente che i client lo contattino: non dà mai inizio a una connessione. Per fare un esempio del mondo reale, immaginiamo un server web. Il server web aspetta che un browser (il client) si colleghi e richieda una pagina web. Quindi restituisce i dati richiesti al client e poi resta in attesa della richiesta successiva. Ogni volta che si seleziona un link, si fa clic su un pulsante oppure si digita un testo in un campo di testo nella finestra di un browser, si crea una richiesta che viene inviata al server web. La classe Server è la classe di base della classe EthernetServer della libreria Ethernet. Non viene chiamata direttamente, ma viene utilizzata dalle altre classi. Come nel caso di IPAddress, la sorgente della classe Server si trova nella directory Arduino/hardware/arduino/avr/cores/arduino della sorgente di Arduino. EthernetServer()
Stabilisce la porta da utilizzare quando si rimane in attesa di una richiesta di collegamento da parte di un client. Di solito la porta viene specificata quando viene istanziato un oggetto di tipo EthernetServer. Non restituisce niente (void).
Esempio:
Il valore dell’argomento port può essere un numero qualsiasi compreso tra 0 e 65535, ma di solito i valori da 0 a 1024 sono riservati per servizi di sistema come FTP, SSH e possibilmente un server web. Per evitare conflitti, conviene assegnare alle porte valori rappresentati da numeri molto alti (superiori a 9000, per esempio). begin()
Chiede al server di cominciare ad aspettare i collegamenti da parte dei client sulla porta che è stata impostata al momento della creazione dell’oggetto server.
available()
Restituisce una connessione con un client collegato e pronto per comunicare.
write()
Scrive dati su un client collegato a un server. I dati vengono scritti su tutti i client collegati. Accetta un valore rappresentato da un unico carattere (o byte), oppure un puntatore a un array di valori di tipo char e restituisce il numero di byte scritti.
print()
Stampa dati su tutti i client collegati a un server nella forma di una sequenza di caratteri ASCII. println()
Simile a print(), ma aggiunge un carattere di ritorno a capo alla fine dell’output. Accetta dati di tipo char, byte (uint8_t), int, long o string. Restituisce il numero di byte scritti. In assenza di argomenti, la funzione si limita a inviare un carattere di ritorno a capo.
La classe Client: EthernetClient La classe Client crea oggetti client, che possono collegarsi a un server per inviare e ricevere dati. Generalmente un client inizia una transazione, o scambio, di dati con un server. Un server resta in ascolto e in attesa di un client che voglia collegasi e, una volta
avvenuta la connessione, il client può richiedere dati al server, inviare dati al server, oppure richiedere che il server esegua qualche azione da parte sua. La classe Client è la classe di base della classe EthernetClient del la libreria Ethernet. Non viene chiamata direttamente: la classe EthernetClient eredita da essa. Come nel caso di Server, la sorgente della classe di base Client si trova nella directory Arduino/hardware/arduino/avr/cores/arduino della sorgente di Arduino. EthernetClient()
Crea un oggetto client che sia in grado di collegarsi a un server presso un indirizzo IP specifico utilizzando una porta specifica. Per definire il server e la porta da utilizzare, si utilizza il metodo connect(). Per esempio:
connected()
Determina se un client è collegato o meno, restituendo true o false.
connect()
Crea il collegamento con un server presso un indirizzo IP (un array di quattro byte) specifico e una porta specifica. Anziché un indirizzo IP, si può utilizzare un URL (indirizzo web).
Restituisce un numero intero che rappresenta lo stato del collegamento:
write()
Invia un valore oppure i contenuti di un buffer al server collegato. I dati vengono inviati nella forma di una serie di byte. Il metodo write() restituisce il numero di byte scritti. Questo valore restituito può essere tranquillamente ignorato.
print()
Stampa dati sul server collegato, nella forma di una sequenza di caratteri ASCII. Accetta dati di tipo char, byte (uint8_t), int, long, oppure string. Può anche accettare una base specificata. I tipi base validi sono BIN (binario), DEC (base 10), OCT (base 8) ed HEX (base 16). Restituisce il numero di byte scritti.
println()
Identico al metodo print(), a eccezione che per il fatto che alla fine dell’output di caratteri ASCII viene aggiunto un ritorno a capo. Un println() privo di parametri invia al server collegato soltanto un ritorno a capo.
Restituisce il numero di caratteri disponibili da leggere provenienti dal server collegato. Può essere utilizzato per verificare se sono presenti dati in arrivo.
read()
Legge il successivo byte disponibile che proviene dal server. Utilizza un ciclo per leggere diversi caratteri, oppure legge e valuta ciascun carattere uno alla volta.
flush()
Elimina tutti i caratteri provenienti dal server e non letti che si trovano nel buffer di ricezione.
stop()
Si sconnette dal server attualmente collegato. Una volta scollegato, il client può connettersi con un altro server (oppure nuovamente con lo stesso server, naturalmente).
La classe EthernetUDP A differenza di TCP/IP, che è un protocollo di streaming (cioè che non ha limiti definiti di inizio e fine), UDP è un protocollo di datagramma. Ciascun elemento di dati è un singolo pacchetto, detto datagramma, e i dati devono entrare nei limiti del pacchetto del datagramma. UDP non è dotato di rilevamento degli errori, né garantisce la consegna dei dati, ma, nel caso di pacchetti corti di dati non fondamentali, o dove il software di
livello superiore è in grado di gestire cose come il rilevamento degli errori e i nuovi tentativi, rappresenta un modo veloce e relativamente semplice di spostare dati tra host. begin()
Inizializza la classe specifica.
UDP
per iniziare ad aspettare i dati in arrivo su una porta
read()
Legge i dati in arrivo dal buffer specificato. Se non viene fornito nessun parametro, restituisce un carattere del buffer corrente. Se sono specificati il buffer e la dimensione, restituisce fino a maxsize byte del buffer.
Notate che questa funzione è pensata per essere utilizzata immediatamente dopo una chiamata a UDP.parsePacket(). write()
Invia dati a un collegamento remoto. La funzione write() deve essere inserita tra le chiamate beginPacket() ed endPacket(). beginPacket() inizializza il pacchetto di dati e in realtà è la chiamata endPacket() a inviare i dati all’host remoto.
beginPacket()
Apre un collegamento UDP con un host remoto su un indirizzo IP specifico e una porta specifica. Restituisce 1 (true) se il collegamento avviene correttamente, oppure 0 in caso contrario.
endPacket()
Invia un pacchetto UDP creato dalla funzione write() all’host remoto specificato dalla funzione beginPacket().
parsePacket()
Controlla su un collegamento UDP aperto se è presente un pacchetto datagramma e restituisce la dimensione dei dati in attesa. parsePacket() deve essere chiamato prima di read() oppure, per ricavare i dati (se ce ne sono), si utilizza la funzione available().
available()
Restituisce il numero di byte dei dati ricevuti che attualmente si trovano nel buffer di ricezione. Notate che deve essere chiamato solo dopo una chiamata a parsePacket().
stop()
Si scollega dall’host UDP remoto e si libera di tutte le sorgenti utilizzate durante la sessioneUDP.
remoteIP()
Restituisce l’indirizzo IP del collegamento UDP remoto nella forma di un array di 4 byte. Questa funzione deve essere chiamata soltanto dopo una chiamata a parsePacket().
remotePort()
Restituisce la porta UDP del collegamento UDP remoto nella forma di un numero intero. Questa funzione deve essere chiamata soltanto dopo una chiamata a parsePacket().
Firmata Firmata è un’interessante libreria con moltissime applicazioni potenziali. Firmata mette a disposizione i mezzi per utilizzare comunicazioni seriali tra Arduino e un’applicazione o un computer host utilizzando un protocollo simile al MIDI. È stata sviluppata con l’obiettivo di permettere di controllare più funzionalità di Arduino possibili con un computer host: in altre parole, di utilizzare Arduino come se fosse un’estensione delle funzionalità I/O dell’host. Prima di imbarcarsi in un progetto Firmata per la prima volta, conviene provare il software dimostrativo. Potete scaricare un client adatto dalla vecchia wiki di Firmata (http://firmata.org/wiki/Main_Page) e la porzione di codice Arduino è già inclusa nelle librerie distribuite con l’IDE di Arduino. Questo paragrafo presenta soltanto un riepilogo delle funzioni disponibili nella libreria Firmata. Il prossimo elenco mostra l’organizzazione dei componenti della libreria. Sfortunatamente, questi componenti non sembrano essere accuratamente documentati e quindi qualcosa di quello che potete voler scoprire per utilizzarli deve essere intuito nel codice sorgente. Per maggiori dettagli ed esempi di utilizzo, potete consultare la wiki di Firmata (http://firmata.org/, ormai abbandonata e non più supportata) oppure il
repository Firmata di GitHub (https://github.com/firmata). Cercate di prestare particolarmente attenzione alla definizione del protocollo (https://github.com/firmata/protocol), dal momento che è quello che utilizza l’applicazione host per comunicare con un’applicazione Firmata attiva su Arduino. SUGGERIMENTO Il codice della libreria Firmata incluso nell’IDE di Arduino può non essere la versione più recente, per cui vi conviene guardare nel repository di GitHub (https://github.com/firmata/arduino). La documentazione presentata qui può fare riferimento a funzioni che non sono presenti nella vostra versione.
La libreria Firmata è organizzata così: •
Metodi di base
•
– begin() – printVersion() – blinkVersion() – printFirmwareVersion() – setFirmwareVersion() Inviare messaggi
•
– sendAnalog() – sendDigitalPorts() – sendDigitalPortPair() – sendSysex() – sendString() – sendString() Ricevere messaggi
•
– available() – processInput() Funzioni di callback
•
– attach() – detach() Tipi di messaggi
I metodi di base Nei prossimi paragrafi, analizzeremo una a una ciascuna di queste categorie. begin()
La forma base di begin() inizializza la libreria Firmata e imposta la velocità dei dati seriali su quella predefinita di 57.600 baud. La seconda forma accetta un argomento di tipo long, che contiene il baud rate desiderato per la comunicazione tra Firmata e un sistema host. La terza forma avvia la libreria utilizzando uno stream diverso da Serial. È pensata per funzionare con qualsiasi flusso di dati che implementi
l’interfaccia Stream (Ethernet, WiFi, ecc.). Per ulteriori informazioni sullo stato attuale di questo metodo, potete consultare le discussioni sulla pagina Firmata di GitHub (https://github.com/firmata/arduino/issues).
printVersion()
Invia la versione del protocollo della libreria al computer host.
blinkVersion()
Fa lampeggiare la versione del protocollo sul pin 13 (il LED integrato sulla scheda Arduino).
printFirmwareVersion()
Invia il nome e la versione del firmware al computer host.
setFirmwareVersion()
Imposta il nome e la versione del firmware utilizzando il nome di file dello sketch, meno l’estensione.
Inviare messaggi sendAnalog()
Invia un messaggio di dati analogico.
sendDigitalPort()
Invia lo stato delle porte digitali nella forma di singoli byte.
sendString()
Invia una stringa al computer host.
sendString()
Invia una stringa al computer host utilizzando un tipo di comando personalizzato.
sendSysex()
Invia un comando che contenga un array arbitrario di byte.
Ricevere messaggi available()
Controlla se stanno arrivando messaggi nel buffer di input.
processInput()
Ricava ed elabora i messaggi in arrivo dal buffer di input e invia i dati alle funzioni di callback registrate.
Funzioni di callback Per poter associare una funzione a un tipo specifico di messaggio, la funzione deve corrispondere a una funzione di callback. In Firmata esistono tre tipi fondamentali di funzioni di callback. Li vedremo uno a uno nei prossimi paragrafi: generico, stringa e sysex e un quarto tipo per gestire il reset del sistema. Le funzioni di callback sono: attach()
Associa una funzione a un tipo specifico di messaggio in arrivo.
detach()
Scollega una funzione da un tipo specifico di messaggio in arrivo.
Tipi di messaggi Una funzione può essere associata a un tipo specifico di messaggio. Firmata mette a disposizione questi tipi di messaggi: ANALOG_MESSAGE
Il valore analogico di un singolo pin DIGITAL_MESSAGE
Otto bit di dati di un pin digitale (una porta) REPORT_ANALOG
Attiva/disattiva il reporting di un pin analogico REPORT_DIGITAL
Attiva/disattiva il reporting di una porta digitale SET_PIN_MODE
Cambia la modalità del pin tra INPUT/OUTPUT/PWM/ecc. FIRMATA_STRING
Per le stringhe in stile C; per il tipo di funzione utilizza stringCallbackFunction SYSEX_START
Per messaggi generici di lunghezza arbitraria (per mezzo del protocollo MIDI SysEx); per il tipo di funzione utilizza sysex CallbackFunction SYSTEM_RESET
Resetta il firmware sul suo stato predefinito; per il tipo di funzione utilizza systemResetCallbackFunction
GSM La libreria GSM si utilizza con la shield GSM per collegarsi a una rete GSM/GPRS. È inclusa con le versioni 1.0.4 e successive dell’IDE di Arduino. La libreria GSM supporta la maggior parte delle funzioni che ci si aspetta di trovare su un telefono GSM, come la possibilità di eseguire e ricevere chiamate, inviare e ricevere messaggi SMS e collegarsi a Internet per mezzo di una rete GPRS. GSM sta per “global system for mobile communications” e GPRS è l’acronimo di General Packet Radio Service. Per trasferire dati da una porta seriale alla rete GSM, la shield GSM incorpora un modem. Il modem utilizza comandi di tipo AT per eseguire diverse funzioni. In un utilizzo normale, ciascun comando AT fa parte di una serie più lunga che esegue una funzione specifica. Per supportare la comunicazione tra Arduino e il modem GSM, la libreria GSM si appoggia alla libreria SoftwareSerial. NOTA La libreria GSM è un’aggiunta recente. Se avete una versione più vecchia dell’IDE, è possibile che non ne disponiate. Per vedere se avete a vostra disposizione o meno la libreria GSM, dovete consultare l’elenco di librerie disponibili nell’IDE.
La suite di classi della libreria GSM è complessa e una descrizione completa di tutte le funzionalità andrebbe oltre l’ambito di questo libro. Questo paragrafo presenta un riepilogo della funzionalità. Per informazioni più dettagliate, potete consultare la guida della libreria GSM di Arduino (https://www.arduino.cc/en/Reference/GSM) oppure l’aiuto integrato dell’IDE di Arduino. Inoltre alcuni distributori, come Adafruit, producono shield GSM compatibili con Arduino e per questi prodotti mettono a disposizione le loro librerie.
La compatibilità con la libreria Ethernet La libreria GSM è ampiamente compatibile con l’attuale libreria Ethernet di Arduino, tanto che un programma di porting che utilizzi le librerie Ethernet o WiFi di Arduino per GSM da utilizzare con la shield GSM dovrebbe risultare relativamente semplice. Saranno necessarie alcune modifiche specifiche per la libreria, come includere le librerie specifiche per GSM e GPRS e ottenere le impostazioni di rete dal nostro provider del network cellulare. La struttura della libreria La libreria GSM è piuttosto complessa ed è costituita da 10 classi principali. Ecco le funzioni di ciascuna delle classi di GSM: •
Classe GSM
•
– begin() – shutdown() Classe GSMVoiceCall
•
– getVoiceCallStatus() – ready() – voiceCall() – answerCall() – hangCall() – retrieveCallingNumber() Classe GSM_SMS
•
– beginSMS() – ready() – endSMS() – available() – remoteNumber() – read() – write() – print() – peek() – flush() Classe GPRS
•
– attachGPRS() Classe GSMClient – –
ready() connect()
•
– beginWrite() – write() – endWrite() – connected() – read() – available() – peek() – flush() – stop() Classe GSMServer
•
– ready() – beginWrite() – write() – endWrite() – read() – available() – stop() Classe GSMModem
•
– begin() – getIMEI() Classe GSMScanner
•
– begin() – getCurrentCarrier() – getSignalStrength() – readNetworks() Classe GSMPIN
•
– begin() – isPIN() – checkPIN() – checkPUK() – changePIN() – switchPIN() – checkReg() – getPINUsed() – setPINUsed() Classe GSMBand
– – –
begin() getBand() setBand()
La classe GSM Questa classe prepara le funzioni che comunicheranno con il modem. Gestisce la connettività della shield ed esegue la registrazione di sistema necessaria con l’infrastruttura GSM. Per gestire le funzioni di comunicazione a basso livello, tutti i programmi GSM/GPRS di Arduino devono includere un oggetto di questa classe. Questa è la classe di base di tutte le funzioni che si basano su GSM. Deve essere istanziata così:
begin()
Avvia il modem GSM/GPRS e lo associa a una rete GSM. Ecco come si presenta il prototipo completo del metodo begin():
Il metodo begin() può essere chiamato in quattro modi diversi perché a ciascun argomento è assegnato un valore predefinito. La prima forma non accetta argomenti e dà per scontato che la SIM non abbia nessun pin configurato.
shutdown()
Spegne il modem (gli toglie l’alimentazione).
La classe GSMVoiceCall La classe GSMVoiceCall attiva la comunicazione vocale per mezzo del modem, ammesso che alla shield GSM siano collegati un microfono, un altoparlante e un piccolo circuito. Questa è la classe di base di tutte le funzioni GSM che si utilizzano per ricevere ed effettuare chiamate vocali e deve essere istanziata così:
getVoiceCallStatus()
Restituisce lo stato di una chiamata vocale nella forma di RECEIVINGCALL, oppure TALKING.
IDLE_CALL, CALLING,
ready()
Restituisce lo stato dell’ultimo comando: 1 se l’ultimo comando è stato eseguito correttamente, 0 se l’ultimo comando è ancora in esecuzione e >1 se si è verificato un errore.
voiceCall()
Effettua una chiamata vocale in modalità asincrona oppure sincrona. Nel primo caso, voiceCall() restituisce un valore mentre si chiama il numero. Nella modalità sincrona, voiceCall() non restituisce niente finché la chiamata non inizia oppure viene annullata. Il primo argomento è una stringa che contiene il numero da chiamare. È possibile utilizzare o meno un prefisso internazionale. Il buffer non deve essere cancellato o utilizzato finché voiceCall() non è completo (il comando è terminato). L’argomento timeout è espresso in millisecondi e viene utilizzato soltanto nella modalità sincrona. Se impostato su 0, voiceCall() aspetta indefinitamente che l’altro risponda.
answerCall()
Accetta una chiamata vocale in arrivo. Nella modalità asincrona, answerCall() restituisce 0 se l’ultimo comando è ancora in esecuzione, 1 se è stato eseguito correttamente e >1 se si è verificato un errore. Nella modalità sincrona, answerCall() restituisce 1 se si risponde alla chiamata e 0 in caso contrario.
hangCall()
Risponde a una chiamata iniziata o a uno squillo. Nella modalità asincrona, hang Call() restituisce 0 se l’ultimo comando è ancora in esecuzione, 1 se è stato eseguito correttamente e >1 se si è verificato un errore. Nella modalità sincrona, hangCall() restituisce 1 se si risponde alla chiamata e 0 in caso contrario.
retrieveCallingNumber()
Ricava il numero che chiama e lo inserisce in un buffer. Il buffer dell’argomento è un puntatore a un buffer di caratteri e bufsize è la dimensione del buffer, espressa in byte. Il buffer deve essere sufficientemente grande da contenere almeno 10
caratteri. Nella modalità asincrona, retrieveCallingNumber() restituisce 0 se l’ultimo comando è ancora in esecuzione, 1 se è stato eseguito correttamente e >1 se si è verificato un errore. Nella modalità sincrona, retrieveCallingNumber() restituisce 1 se il numero è stato acquisito correttamente e 0 in caso contrario.
La classe GSM_SMS Questa classe fornisce la possibilità di inviare e ricevere messaggi SMS (Short Message Service). beginSMS()
Definisce il numero di telefono per ricevere un messaggio SMS. Il numero di telefono è un array di caratteri. Nella modalità asincrona, la funzione restituisce 0 se l’ultimo comando è ancora attivo, 1 se è stato eseguito correttamente e un valore >1 se si è verificato un errore. Nella modalità sincrona, la funzione restituisce 1 se il comando precedente è stato eseguito correttamente e 0 in caso contrario.
ready()
Restituisce lo stato dell’ultimo comando GSM SMS. Nella modalità asincrona, ready() restituisce 0 se l’ultimo comando è ancora attivo, 1 se è stato eseguito correttamente e un valore >1 se si è verificato un errore. Nella modalità sincrona, la funzione restituisce 1 se il comando precedente è stato eseguito correttamente e 0 in caso contrario.
endSMS()
Si utilizza per informare il modem del fatto che il messaggio è completo e pronto per essere inviato. Nella modalità asincrona, la funzione restituisce 0 se è ancora in esecuzione, 1 se è stato eseguito correttamente e >1 se si è verificato un errore. Nella modalità sincrona, restituisce 1 se è stato eseguito correttamente e 0 in caso contrario.
available()
Se un messaggio SMS è disponibile per essere letto, questa funzione restituisce il numero di caratteri che contiene. Se non è disponibile nessun messaggio, restituisce 0.
remoteNumber()
Estrae il numero di telefono remoto da un messaggio SMS in arrivo e lo restituisce in un array di caratteri. L’argomento size definisce la dimensione massima dell’array passato a remoteNumber(). Nella modalità asincrona, la funzione restituisce 0 se è ancora in esecuzione, 1 se è stato eseguito correttamente e >1 se si è verificato un errore. Nella modalità sincrona, la funzione restituisce 1 se è stato eseguito correttamente, 0 in caso contrario.
read()
Legge un byte (un carattere) da un messaggio SMS. Restituisce il byte nella forma di un numero intero, oppure -1 se non ci sono dati disponibili.
write()
Scrive un carattere in dimensione di byte in un messaggio SMS.
print()
Scrive un array di caratteri in un messaggio SMS. Restituisce il numero di byte che è riuscito a scrivere.
peek()
Restituisce il byte (un carattere) disponibile successivo di un messaggio SMS, senza eliminare il carattere, oppure -1 se non ci sono dati disponibili.
flush()
Cancella dal modem tutti i messaggi inviati dopo che sono stati inviati tutti i caratteri in uscita.
La classe GPRS GPRS è la classe di base di tutte le funzioni GPRS. Questo include le funzioni client e
server per Internet. Questa classe è inoltre responsabile di includere i file coinvolti con la comunicazione TCP. attachGPRS()
Si collega con un determinato APN (access point name) per iniziare comunicazioni GPRS. I provider di reti cellulari dispongono di APN che fungono da ponti tra la rete
cellulare e Internet. Restituisce una di queste stringhe: ERROR, IDLE, CONNECTING, GSM_READY, GPRS_READY, TRANSPARENT_CONNECTED.
La classe GSMClient Questa classe crea client che possono collegarsi a server e inviare e ricevere dati. ready()
Restituisce lo stato dell’ultimo comando. Nella modalità asincrona, la funzione restituisce 0 se è ancora in esecuzione, 1 se è stato eseguito correttamente e >1 se si è verificato un errore. Nella modalità sincrona, la funzione restituisce 1 se è stato eseguito correttamente e 0 in caso contrario.
connect()
Si collega a porta specifica di un indirizzo IP specificato. Restituisce true se il collegamento è avvenuto correttamente, oppure false in caso contrario.
beginWrite()
Inizia un’operazione di scrittura sul server collegato.
write()
Scrive dati su un server collegato. Restituisce il numero di byte scritti.
endWrite()
Smette di scrivere dati su un server collegato.
connected()
Restituisce lo stato del collegamento di un client. Notate che un client si considera collegato se la connessione è stata chiusa ma nel buffer ci sono dati che non sono stati ancora letti. Restituisce true se il client è collegato, oppure false in caso contrario.
read()
Legge il byte di dati successivo e disponibile proveniente dal server con il quale è collegato il client. Restituisce il byte successivo, oppure -1 se non ci sono dati disponibili.
available()
Restituisce il numero di byte provenienti dal server collegato e che sono in attesa di essere letti.
peek()
Restituisce il byte successivo e disponibile di un messaggio in arrivo senza eliminarlo dal buffer. Le chiamate successive a peek() si limitano a restituire lo stesso byte.
flush()
Elimina tutti i dati attualmente in attesa nel buffer e resetta il conteggio dei dati disponibili riportandolo a zero.
stop()
Forza la disconnessione dal server.
La classe GSMServer La classe GSMServer crea server che possono inviare dati a client collegati e riceverne da essi. Implementa funzionalità server di rete, simili a quelli delle librerie Ethernet e WiFi. Notate che alcuni operatori di rete non ammettono connessioni di rete in entrata provenienti dall’esterno delle loro reti. ready()
Restituisce lo stato dell’ultimo comando. Nella modalità asincrona, questa funzione restituisce 0 se è ancora in esecuzione, 1 se è stato eseguito correttamente e >1 se si è verificato un errore. Nella modalità sincrona, la funzione restituisce 1 se è stato eseguito correttamente e 0 in caso contrario.
beginWrite()
Inizia un’operazione di scrittura su tutti i client collegati.
write()
Scrive dati sui client collegati. Restituisce il numero di byte scritti.
endWrite()
Interrompe la scrittura dei dati sui client collegati.
read()
Legge il byte successivo disponibile, proveniente da un client collegato. Restituisce il byte letto, oppure -1 se non ci sono dati disponibili.
available()
Rimane in attesa di richieste di collegamento da parte dei client. Restituisce il numero di client collegati.
stop()
Fa in modo che il server smetta di aspettare le richieste di collegamento dei client.
La classe GSMModem La classe GSMModem mette a disposizione funzioni diagnostiche di supporto per i modem GSM interni. begin()
Controlla lo stato del modem e lo riavvia. Questa funzione deve essere chiamata prima di chiamare getIMEI(). Restituisce 1 se il modem funziona correttamente, oppure un errore in caso contrario.
getIMEI()
Chiede al modem di ricavare il suo numero IMEI (International Mobile Equipment Identifier). Il numero IMEI viene restituito in forma di stringa. Questa funzione deve essere chiamata soltanto dopo una chiamata a begin().
La classe GSMScanner
La classe GSMScanner fornisce funzioni per ottenere informazioni diagnostiche sul network e sull’operatore. begin()
Resetta il modem. Restituisce 1 se il modem sta funzionando correttamente, un codice di errore in caso contrario.
getCurrentCarrier()
Restituisce il nome dell’attuale network server provider (l’operatore) in forma di stringa.
getSignalStrength()
Restituisce la potenza relativa di segnale del collegamento di rete in forma di stringa, con cifre ASCII da 0 a 31 (31 indica che la potenza è > 51 dBm), oppure 99 se non viene rilevato nessun segnale.
readNetworks()
Cerca operatori di rete disponibili. Restituisce una stringa che contiene l’elenco degli operatori rilevati.
La classe GSMPIN La classe GSMPIN contiene funzioni utility per comunicare con la scheda SIM. begin()
Resetta il modem. Restituisce 1 se il modem sta funzionando correttamente, un codice di errore in caso contrario.
isPIN()
Esamina la scheda SIM per determinare se è bloccata con un PIN o meno. Restituisce 0 se il blocco per mezzo del PIN è disattivato, 1 se il blocco è attivato, -1 se è attivato il blocco per mezzo del PUK e -2 se si è verificato un errore.
checkPIN()
Invia un PIN alla scheda SIM per determinare se è valido o meno. Restituisce 0 se il PIN è valido e -1 se non lo è.
checkPUK()
Invia un codice PUK alla scheda SIM per determinare se è valido e stabilisce una nuovo codice PIN. Restituisce 0 se tutto è avvenuto correttamente e -1 in caso contrario.
changePIN()
Cambia il codice PIN di una scheda SIM dopo aver verificato che il vecchio PIN sia valido.
switchPIN()
Cambia lo stato di blocco per mezzo del PIN.
checkReg()
Cerca di determinare se il modem è registrato in una rete GSM/GPRS. Restituisce 0 se il modem è registrato, 1 se il modem è in roaming e -1 se si è verificato un errore.
getPINUsed()
Cerca di determinare se si sta utilizzando il blocco del PIN. Restituisce true se è attivato e false in caso contrario.
setPINUsed()
Imposta lo stato del blocco del PIN. Se l’argomento è true, il PIN è bloccato; se è false, è sbloccato.
La classe GSMBand La classe GSMBand fornisce informazioni sulla banda di frequenza alla quale si collega il modem. Esistono anche metodi per impostare la banda. begin()
Resetta il modem. Restituisce 1 se il modem sta funzionando correttamente, un codice di errore in caso contrario.
getBand()
Restituisce la banda di frequenza che sta attualmente utilizzando il modem per collegarsi.
setBand()
Imposta la banda di frequenza che che deve utilizzare il modem.
LiquidCrystal Questa classe permette a una scheda Arduino di controllare un modulo LCD (liquid crystal display). È pensata specificamente per LCD che si basano sul chipset Hitachi HD44780 (o compatibile), che si trova sulla maggior parte degli LCD basati sul testo. La libreria supporta la modalità di interfaccia sia a 4 che a 8 bit e utilizza anche tre dei pin di Arduino per le linee di controllo RS (register select), clock enable e R/W (read/write, lettura/scrittura). LiquidCrystal()
Crea un’istanza di un oggetto di classe LiquidCrystal. Le diverse forme della classe permettono di adattarla a diversi metodi di interfaccia LCD.
Dove: rs rw enable d0 .. d7
Il pin di Arduino collegato al pin RS dell’LCD Il pin di Arduino collegato al pin RW dell’LCD Il pin di Arduino collegato al pin enable dell’LCD I pin di Arduino collegati ai pin dati dell’LCD
L’utilizzo dei segnali d4, d5, d6 e d7 è facoltativo. Se vengono utilizzate soltanto quattro linee digitali, questi possono essere omessi. Esempio:
begin()
Inizializza l’interfaccia sul controller LCD del modulo LCD. Gli argomenti specificano la larghezza e l’altezza dell’LCD. La dimensione predefinita dei caratteri è 5 × 8 pixel.
Questa funzione deve essere chiamata prima che possa essere utilizzata qualsiasi altra funzione della libreria LCD.
clear()
Cancella gli schermi LCD e riporta il cursore nell’angolo in alto a sinistra.
home()
Posiziona il cursore in alto a sinistra sull’LCD. Non cancella l’LCD: per farlo si deve utilizzare la funzione clear().
setCursor()
Posiziona il cursore nel punto specificato dagli argomenti column e row.
write()
Scrive un byte (char) di dati sull’LCD. Restituisce il numero di byte scritti.
print()
Questa funzione in realtà fa parte del codice standard di runtime AVR-GCC di Arduino ed è overloaded in modo che possa accettare dati di diversi tipi. Il file Print.h, che si trova in hardware/arduino/avr/cores/arduino/Print.h, definisce queste forme della funzione print():
cursor()
Attiva il cursore, un carattere di sottolineatura, nella posizione dove verrà scritto il carattere successivo sullo schermo LCD.
noCursor()
Disattiva il cursore, in realtà nascondendolo. Non ha conseguenze sulla posizione dove apparirà il carattere successivo.
blink()
Fa apparire un cursore lampeggiante.
noBlink()
Disattiva il cursore lampeggiante.
display()
Attiva l’LCD, se prima era stato disattivato con la funzione noDisplay(). Ripristina il cursore e tutto il testo che prima era visibile o che può essere stato aggiunto, cancellato o modificato a partire dal momento in cui il display è stato disattivato.
noDisplay()
Disattiva il display LCD senza alterare il testo esistente sullo schermo.
scrollDisplayLeft()
Fa scorrere il testo sul display di uno spazio a sinistra.
scrollDisplayRight()
Fa scorrere il testo sul display di uno spazio a destra.
autoscroll()
Attiva lo scorrimento automatico. Quando nel display viene aggiunto del testo, sposta i caratteri esistenti di uno spazio a sinistra oppure a destra, a seconda della direzione corrente del testo.
noAutoscroll()
Disattiva la funzione di scorrimento automatico dell’LCD.
leftToRight()
Imposta la direzione nella quale scorre il testo quando si attiva lo scorrimento automatico, in questo caso da sinistra a destra.
rightToLeft()
Imposta la direzione nella quale scorre il testo quando si attiva lo scorrimento automatico, in questo caso da destra a sinistra.
createChar()
Crea un carattere personalizzato di 5 × 8 pixel. Il carattere è definito da un array di byte, uno per riga. Vengono utilizzati soltanto gli ultimi cinque bit meno significativi di ciascun byte.
SD La libreria SD fornisce il supporto per leggere e scrivere schede di memoria flash SD, sia a dimensione normale che micro (in termini di interfaccia e di funzioni sono identiche, cambia soltanto la dimensione). La libreria si basa su sdfatlib di William Greiman. Questa libreria tratta una scheda SD come se fosse un piccolo disco con filesystem FAT16 o FAT32. Utilizza nomi di file corti (formato 8.3). I nomi di file passati alle funzioni della libreria SD possono includere un percorso, con nomi di directory separati da barre (come quelle di Linux, non le barre invertite che si utilizzano su MS-DOS o su Windows). Per comunicare con la scheda SD si utilizza l’interfaccia SPI. Su una scheda Arduino standard, questa utilizza i pin digitali 11, 12 e 13. Come pin select si utilizza un ulteriore pin, di solito il pin 10, oppure questo ruolo può essere assegnato a un altro pin. Notate che anche se per select si utilizza un altro pin, perché la libreria funzioni il pin SS (pin 10) deve rimanere utilizzato come output. La classe SD La classe SD fornisce funzioni per accedere alla scheda SD e manipolare file e cartelle. begin()
Inizializza la libreria SD e l’interfaccia con la scheda SD. L’argomento facoltativo csPin definisce il pin da utilizzare come select. L’opzione predefinita è il pin 10 (SD_CHIP_SELECT_PIN). Questa funzione deve essere chiamata prima che possano essere utilizzate tutte le altre funzioni SD. Restituisce true se tutto è avvenuto correttamente, false in caso contrario.
exists()
Verifica la presenza di un file o di una directory sulla scheda SD. La stringa filepath può essere un FQPN (fully qualified path name). Restituisce true se il file o la directory esiste, false in caso contrario.
mkdir()
Crea una directory sulla scheda SD. Crea anche tutte le directory intermedie necessarie. Restituisce true se la directory viene creata correttamente, false in caso contrario.
open()
Apre un file su una scheda SD, per leggerlo oppure scriverlo. Se non viene fornito l’argomento mode, l’opzione predefinita è aprire il file per leggerlo. Restituisce un oggetto File che può essere verificato come un valore booleano. Se il file non può essere aperto, File produce false. Le modalità disponibili sono FILE_READ e FILE_WRITE.
remove()
Elimina (rimuove) un file dalla scheda SD. filepath è un FQPN. Restituisce true se tutto è avvenuto correttamente, false in caso contrario.
rmdir()
Elimina un’eventuale cartella vuota da una scheda SD. Restituisce true se la directory è stata eliminata correttamente, oppure false se si è verificato un errore (per esempio se la directory non era vuota).
La classe File La classe File fornisce funzioni per leggere e scrivere singoli file su una scheda SD. Gli oggetti di tipo File sono creati dalla funzione SD.open():
Nell’oggetto File esistono numerosi metodi per manipolare i contenuti di un file: available()
Restituisce il numero di byte disponibili da leggere su un file.
close()
Chiude un file, assicurando che prima vengano scritti tutti i dati rimanenti.
flush()
Scrive nel file i dati rimanenti in un buffer. Non chiude il file.
peek()
Legge un byte in un file senza far avanzare il puntatore di dati interno. Le chiamate successive a peek() restituiscono lo stesso byte.
position()
Restituisce la posizione corrente nel file a partire dalla quale verrà letto o scritto il prossimo byte.
print()
Scrive dati in un file che è stato aperto per essere scritto. Accetta dati di tipo char, byte (uint8_t), int, long o string. Può anche accettare una base specificata. I tipi validi di base sono BIN (binario), DEC (base 10), OCT (base 8) e HEX (base 16). Restituisce il numero di byte scritti.
Nota: in questo esempio è mostrata la stringa data. println()
Scrive dati in un file che è stato aperto per essere scritto, seguiti da una coppia di caratteri ritorno a capo e nuova riga. Accetta dati di tipo char, byte (uint8_t), int, long o string. Può anche accettare una base specificata. I tipi validi di base sono BIN (binario), DEC (base 10), OCT (base 8) e HEX (base 16). Restituisce il numero di byte scritti.
seek()
Sposta il puntatore interno in una nuova posizione nel file. La posizione deve essere compresa tra 0 e la dimensione del file inclusi. Restituisce true se tutto è stato eseguito correttamente, oppure false se si verifica un errore (si cerca oltre la fine del file, per esempio).
size()
Restituisce la dimensione del file, in byte.
read()
Legge il byte successivo nel file, oppure restituisce un valore di -1 se non ci sono dati disponibili.
write()
Scrive dati in un file. Accetta un unico byte, oppure un oggetto dati che può essere un byte, un carattere o una stringa. L’argomento size definisce la quantità di dati da scrivere sulla scheda SD. Restituisce il numero di byte scritti.
isDirectory()
Restituisce true se l’oggetto fname si riferisce a una directory, altrimenti restituisce false.
openNextFile()
Apre la successiva cartella di file in una directory e restituisce una nuova istanza di un oggetto File.
rewindDirectory()
Questa funzione, che si utilizza con openNextFile(), restituisce il primo file o la prima sottocartella in una directory.
Servo La libreria Servo è una raccolta di funzioni per controllare servomotori, come quelli che si utilizzano sugli aereini RC. Una volta creata un’istanza della classe Servo, si utilizza la
funzione attach() per passare il numero di pin da utilizzare con il servo. Gli impulsi che controllano un servo vengono generati in background. La classe si istanzia così:
attach()
Associa un servomotore a un pin I/O. La seconda forma permette al chiamante di specificare i valori minimo e massimo di tempo di scrittura in microsecondi. Restituisce il numero del canale o 0 se la funzione non riesce nel suo intento.
write()
Imposta l’angolo del servo in gradi. Se il valore è > un’ampiezza di impulso in microsecondi.
200
viene trattato come
read()
Restituisce l’ultima ampiezza di impulso del servo scritta nella forma di un angolo compreso tra 0 e 180 gradi.
writeMicroseconds()
Imposta l’ampiezza di impulso del servo in microsecondi.
readMicroseconds()
Restituisce l’ampiezza di impulso corrente di questo servo in microsecondi.
attached()
Restituisce true se l’oggetto servo è stato associato a un servo fisico.
detach()
Impedisce a un oggetto servo associato di generare impulsi sul pin I/O che gli è stato assegnato.
SPI La libreria SPI supporta l’utilizzo del bus Serial Peripheral Interface (SPI) per la
comunicazione con periferiche compatibili con SPI, di solito chip con interfaccia SPI integrata. Può essere utilizzata anche per le comunicazioni tra due microcontroller. La classe SPISettings serve a configurare la porta SPI. Gli argomenti sono combinati in un unico oggetto SPISettings, che viene passato a SPI.beginTransaction().
Esempio:
beginTransaction()
Inizializza l’interfaccia SPI usando le impostazioni definite in un oggetto SPISettings.
endTransaction()
Interrompe la comunicazione con l’interfaccia SPI. Di solito viene chiamato dopo che il pin select è de-asserted per permettere ad altre librerie di utilizzare l’interfaccia SPI.
usingInterrupt()
Si utilizza quando le comunicazioni SPI devono avere luogo all’interno del contesto di un interrupt.
begin()
Avvia la libreria SPI e inizializza l’interfaccia SPI. Imposta i pin SCK, MOSI e SS sulla modalità di output e imposta SCK e MOSI su low mentre SS è high.
end()
Disattiva l’interfaccia SPI ma non modifica le modalità dei pin (in o out).
transfer()
Trasferisce un byte sull’interfaccia SPI, inviando o ricevendo.
setBitOrder()
Imposta l’ordine dei bit shiftati verso l’interfaccia SPI. Le due scelte sono LSBFIRST
(prima il bit meno significativo) e MSBFIRST (prima il bit più significativo). Questa funzione non deve essere utilizzata con progetti nuovi. Per configurare l’interfaccia SPI si deve utilizzare la funzione beginTransaction().
setClockDivider()
Imposta il divisore del clock SPI relativo al clock del sistema. Nel caso delle schede Arduino che si basano su AVR, i divisori validi sono 2, 4, 8, 16, 32, 64, oppure 128. Questa funzione non deve essere utilizzata con progetti nuovi. Per configurare l’interfaccia SPI si deve utilizzare la funzione beginTransaction().
setDataMode()
Imposta la polarità del clock e la fase dell’interfaccia SPI. Questa funzione non deve essere utilizzata con progetti nuovi. Per configurare l’interfaccia SPI si deve utilizzare la funzione beginTransaction().
SoftwareSerial La libreria SoftwareSerial implementa la comunicazione seriale software sul pin I/O digitale di Arduino. In altre parole, si tratta di un “bit-banger” che emula un’interfaccia seriale convenzionale e che si rivela utile quando sono necessarie più interfacce seriali, ma l’USART integrato nel microcontroller AVR è assegnato a qualche altra funzione (come un’interfaccia USB). La libreria SoftwareSerial supporta interfacce seriali multiple, ciascuna con una velocità di fino a 115.200 bit al secondo. Quando si utilizzano diverse istanze di SoftwareSerial, si possono ricevere dati soltanto una alla volta. Il pin I/O utilizzato deve supportare gli interrupt dei cambi di pin. SoftwareSerial fornisce un buffer di ricezione da 64 byte per ciascuna istanza di un’interfaccia seriale. Da utilizzare con altre operazioni I/O seriali si crea un oggetto di tipo SoftwareSerial. Il costruttore della classe viene passato ai pin digitali da utilizzare per l’input (rx) e per l’output (tx).
Esempio:
available()
Restituisce il numero di byte che si trovano nel buffer seriale e che sono disponibili per essere letti.
begin()
Imposta il baud rate (la velocità) dell’interfaccia seriale. Baud rate validi sono 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 28800, 31250, 57600 e 115200.
isListening()
Controlla l’interfaccia seriale per vedere se sta ascoltando gli input. Restituisce true se l’interfaccia sta aspettando attivamente input, false in caso contrario.
overflow()
Se l’input supera la dimensione di 64 byte del buffer di ricezione dell’oggetto SoftwareSerial, viene impostato un flag. Chiamare la funzione overflow() restituisce il flag. Se viene restituito true significa che si è verificato un overflow. Per cancellare il flag si deve chiamare la funzione overflow().
peek()
Restituisce il carattere più vecchio del buffer dell’input seriale, ma senza eliminarlo. Le chiamate successive restituiscono lo stesso carattere. Se nel buffer non ci sono byte, peek() restituisce -1.
read()
Restituisce un carattere proveniente da buffer di ricezione e lo elimina. Di solito la funzione read() si utilizza in un ciclo. Restituisce -1 se non ci sono dati disponibili. Notate che soltanto un’istanza di SoftwareSerial può ricevere dati in arrivo in un determinato momento. Per selezionare l’interfaccia attiva si utilizza la funzione listen().
print()
La funzione print() si comporta come la funzione Serial.print(): accetta tutti i tipi di dati che accetterebbe Serial.print(), che comprendono i tipi char, byte (uint8_t), int, long o string, e restituisce il numero di byte scritti.
println()
Identica alla funzione
serial.print(),
eccetto che per la coppia ritorno a
capo/nuova linea (carriage return/line feed, CR/LF) che aggiunge alla fine dell’output. Restituisce il numero di byte scritti. Se non viene fornito nessun dato, semplicemente emette un CR/LF.
listen()
Attiva il listening (la ricezione dei dati) in un’istanza di SoftwareSerial. Soltanto un’istanza di un oggetto SoftwareSerial può ricevere dati in un determinato momento e l’oggetto di cui viene chiamata la funzione listen() diventa il listener attivo. I dati che arrivano su altre istanze dell’interfaccia vengono eliminati.
write()
Trasmette dati dell’interfaccia seriale in forma di byte puri. Si comporta come la funzione Serial.write(). Restituisce il numero di byte scritti.
Stepper La libreria Stepper può essere utilizzata per controllare motori passo-passo sia unipolari che bipolari con l’hardware adatto che gestisca la corrente necessaria. La libreria Stepper ha due forme di costruttori, uno per i motori unipolari e uno per quelli bipolari. Ciascuna crea una nuova istanza della classe Stepper. Viene chiamata all’inizio dello sketch, prima delle funzioni setup() e loop(). L’argomento steps definisce il numero di passi in una rivoluzione completa dell’albero di uscita del motore. Gli argomenti pin1, pin2, pin3 e pin4 specificano i pin digitali da utilizzare.
Esempio:
setSpeed()
Imposta la velocità (la cadenza dei passi) in termini di RPM. Non fa sì che il motore giri, ma si limita a impostare la velocità da utilizzare quando viene chiamata la funzione step().
step()
Chiede al motore di avanzare un determinato numero di passi. Un conteggio positivo fa girare il motore in una direzione e uno negativo lo fa girare nella direzione
opposta.
TFT La libreria TFT (thin-film transistor) display fornisce funzioni per disegnare testo, immagini e forme in un display TFT. È inclusa con le versioni 1.0.5 e successiva dell’IDE di Arduino. Questa libreria semplifica il processo di mostrare immagini grafiche su un display. Si basa sulla libreria ST7735H di Adafruit, che si trova su GitHub (http://bit.ly/ada-st7735). La libreria ST7735H si basa sulla libreria GFX di Adafruit, disponibile anch’essa su GitHub (http://bit.ly/ada-gfx). La libreria TFT è pensata per lavorare con interfacce che utilizzino le funzionalità di comunicazione SPI dei microcontroller AVR. Se la shield TFT include uno slot per scheda SD, la libreria SD può essere utilizzata per leggere e scrivere dati utilizzando un segnale select separato di Arduino. Per la comunicazione con lo schermo e la scheda SD, la libreria TFT si basa sulla libreria SPI, che quindi deve essere anch’essa inclusa in tutti gli sketch che utilizzano la libreria TFT. La classe TFT Il costruttore della classe TFT è disponibile in due forme. Una viene utilizzata quando si utilizzano i pin SPI standard di Arduino (l’hardware SPI) e la seconda forma permette di specificare quali pin utilizzare:
Dove: cs dc rst mosi sclk
Pin select del chip Selezione modalità comando o dati Pin per il reset Pin utilizzato per MOSI se non si utilizza hardware SPI Pin utilizzato per il clock se non si utilizza hardware SPI
Esempio:
La versione Esplora della libreria TFT utilizza pin predefiniti. Non è necessario fare altro che istanziare l’oggetto TFT:
begin()
Si chiama per inizializzare i componenti della libreria TFT. Deve essere chiamato
prima di poter utilizzare qualsiasi altra funzione. Tipicamente viene chiamato nella funzione setup() di uno sketch.
background()
Sovrascrive l’intero schermo del display con un colore a tinta unita. Può essere utilizzato per cancellare il display. Notate che in realtà lo schermo non può mostrare 256 livelli unici per colore, ma che utilizza 5 bit per i colori blu e rosso e 6 bit per il verde.
stroke()
Si chiama prima di disegnare sullo schermo e imposta il colore di linee e bordi. Come la funzione background(), stroke() utilizza 5 bit per i colori blu e rosso e 6 bit per il verde.
noStroke()
Elimina tutti i colori dei bordi.
fill()
Imposta il colore di riempimento di oggetti e testo sullo schermo. Come la funzione stroke(), fill() utilizza 5 bit per i colori blu e rosso e 6 bit per il verde.
noFill()
Disattiva i riempimenti di colore per oggetti e testo.
setTextSize()
Imposta la dimensione del testo scritto da una chiamata alla funzione text(). La dimensione predefinita del testo è 1, cioè 10 pixel. Ciascun aumento nella dimensione del testo aumenta l’altezza del testo sullo schermo di 10 pixel.
text()
Scrive testo sul display presso le coordinate specificate. Il colore del testo si imposta chiamando la funzione fill() prima di chiamare text().
point()
Disegna un punto in una posizione specifica sullo schermo. Il colore del punto è quello specificato da una chiamata precedente alla funzione fill().
line()
Disegna una linea tra le coordinate iniziale e finale utilizzando il colore impostato dalla funzione stroke().
rect()
Disegna un rettangolo che comincia in un punto in alto a sinistra (x, y) con un’altezza e una larghezza specificate.
width()
Rivela la larghezza dello schermo TFT espressa in pixel.
height()
Rivela l’altezza dello schermo TFT espressa in pixel.
circle()
Disegna un cerchio sul display con centro in (x, y) e raggio r.
image()
Disegna un’immagine caricata da una scheda SD sullo schermo in una posizione specificata.
loadImage()
Crea un’istanza di un oggetto PImage utilizzando il nome di file fornito. Il file dell’immagine deve essere di tipo BMP a 24 bit e deve risiedere nella directory root della scheda SD. Utilizza la funzione di PImage loadImage().
PImage
La classe PImage contiene funzioni per incapsulare e disegnare un’immagine bitmap in un display TFT. PImage.height()
Una volta che un’immagine è stata incapsulata in un oggetto PImage, si può chiedere la sua altezza. Questa funzione restituisce l’altezza nella forma di un valore di tipo int. PImage.width()
Restituisce la larghezza dell’oggetto di un’immagine incapsulata nella forma di un valore di tipo int. PImage.isValid()
Restituisce il valore booleano true se l’oggetto dell’immagine contiene un file bitmap valido, oppure false in caso contrario.
WiFi La libreria WiFi fornisce ad Arduino la capacità di collegarsi a una rete wireless. Le descrizioni offerte qui non definiscono tutte le funzioni disponibili nel dettaglio, dal momento che molte di loro sono simili o identiche a quelle che si trovano nella libreria Ethernet. L’aiuto integrato delle versioni più vecchie dell’IDE di Arduino (che, purtroppo, sembrano essere le uniche che si trovano per alcune distribuzioni di Linux mentre sto scrivendo questo libro) non presenta le pagine di riferimento della libreria WiFi, mentre le versioni più recenti sì. Il codice sorgente della libreria sembra essere installata con le versioni più vecchie dell’IDE, o almeno lo è sul mio sistema di sviluppo Kubuntu. La libreria WiFi si utilizza con la libreria SPI per comunicare con il modulo WiFi e una scheda di memoria SD opzionale. Un Arduino di tipo base (vedere Capitolo 4) comunica con la shield WiFi utilizzando i pin SPI 10, 11, 12 e 13. Le schede di tipo Mega utilizzano i pin 10, 50, 51 e 52. Inoltre, su una shield WiFi di Arduino, si utilizza il pin 7 come segnale di handshake tra Arduino e la shield WiFi, e quindi non lo si deve utilizzare per nessun altro scopo. Altre shield WiFi possono presentare gli stessi limiti. La shield WiFi di Arduino può fungere sia da server per accettare collegamenti in entrata, sia da client per creare un collegamento con un server esistente. La libreria mette a disposizione modalità di cifratura WEP e WPA2 Personal, ma non supporta la cifratura WPA2 Enterprise. Inoltre, se un nodo di un server non trasmette il suo SSID (Service Set Identifier), la shield WiFi non può creare un collegamento. Come la libreria Ethernet, la libreria WiFi è formata da una raccolta di cinque classi C++. Quasi tutte le classi ereditano dalle classi genitore, ma nella maggior parte delle applicazioni non ci si deve preoccupare dei dettagli. Tuttavia, se avete bisogno di vedere le definizioni di basso livello delle classi Client, Server, UDP e altre, le potete trovare nella directory libraries/WiFi nel codice sorgente di Arduino. Questo elenco mostra le cinque classi della libreria WiFi e le funzioni membro pubbliche di ciascuna di esse: •
Classe WiFi begin()
•
– disconnect() – config() – setDNS() – SSID() – BSSID() – RSSI() – encryptionType() – scanNetworks() – getSocket() – macAddress() Classe IPAddress
•
– localIP() – subnetMask() – gatewayIP() Classe Server
•
– WiFiServer() – begin() – available() – write() – print() – println() Classe Client
•
– WiFiClient() – connected() – connect() – write() – print() – println() – available() – read() – flush() – stop() Classe UDP – – –
begin() available() beginPacket()
– – – – – – – – –
endPacket() write() parsePacket() peek() read() flush() stop() remoteIP() remotePort()
NOTA La shield WiFi di Arduino WiFi si basa sul chip HDG204 802.11b/g. Ma bisogna fare attenzione, perché altre shield WiFi, come la shield WiFi di Adafruit basata sul chip WiFi TI CC3000, possono utilizzare una libreria diversa, specifica per un determinato chip WiFi. Molte delle funzionalità dovrebbero essere simili a quelle descritte qui, ma ci sono comunque alcune differenze da prendere in considerazione. La libreria Adafruit è disponibile su GitHub (http://bit.ly/ada-cc3000). Trovate maggiori dettagli sul sito web di Adafruit (http://bit.ly/ada-cc3000-wifi).
La classe WiFi Ecco un riepilogo veloce delle classi WiFi. Trovate le descrizioni delle funzioni nella parte dedicata alla libreria Ethernet. La classe WiFi contiene funzioni per inizializzare la libreria e le impostazioni di rete. La definizione della classe si trova nel file include WiFi.h.
La classe IPAddress Come IPAddress della libreria Ethernet, la classe IPAddress della libreria WiFi funge da contenitore per contenere informazioni sulla configurazione di rete.
La classe Server La classe Server crea server che possono accettare collegamenti richiesti da client per scambiare dati. Un client può essere un altro Arduino con una shield WiFi, un computer desktop, un computer portatile o qualsiasi altro dispositivo con funzionalità compatibili con WiFi. Trovate le descrizioni di print() e println() in “La classe Server: EthernetServer” a pagina 168.
La classe Client La classe Client crea client WiFi che possono collegarsi a server per poter inviare e ricevere dati. Un server può essere un altro Arduino con una shield WiFi, un computer desktop, un computer portatile o qualsiasi altro dispositivo con funzionalità compatibili con WiFi. Trovate le descrizioni di print() e println() in “La classe Server:
EthernetServer” a pagina 168.
La classe UDP La classe UDP permette di inviare e di ricevere messaggi brevi utilizzando il protocollo UDP. A differenza di TCP/IP, che è un protocollo di streaming (cioè che non ha limiti definiti di inizio e fine), UDP è un protocollo di datagramma. In questo caso, ciascun elemento di dati è un singolo pacchetto, detto datagramma, e i dati devono entrare nei limiti del pacchetto del datagramma. UDP non è dotato di rilevamento degli errori, né garantisce la consegna dei dati, ma, nel caso di pacchetti corti di dati non fondamentali, o dove il software di livello superiore è in grado di gestire cose come il rilevamento degli errori e i nuovi tentativi, rappresenta un modo veloce e relativamente semplice di spostare dati tra host.
Wire La libreria Wire serve a comunicare con dispositivi di tipo TWI o I2C. Nei Capitoli 2 e 3 trovate ulteriori informazioni sulle funzionalità TWI dei microcontroller AVR. Il Capitolo 8 descrive alcune shield che utilizzano I2C per le comunicazioni con Arduino. E qui di seguito trovate una tabella che definisce dove si trovano i pin TWI su vari tipi di schede Arduino. Nel Capitolo 4 potete osservare i diagrammi dei pinout delle schede. Scheda
SDA SCL
Uno, Ethernet
A4
A5
Mega2560
20
21
Leonardo
2
3
Il cuore della libreria Wire è la classe TwoWire. Esempio:
begin()
Inizializza la libreria TWI e attiva l’interfaccia I2C in modalità master oppure servant. Se non è specificato l’indirizzo, per impostazione predefinita l’interfaccia I2C entra in modalità master.
requestFrom()
Utilizzata dal master dell’interfaccia per richiedere dati a un dispositivo servant. I byte di dati sono ricavati con le funzioni available() e read(). Restituisce il numero di byte di dati letti sul dispositivo.
beginTransmission()
Dà inizio a una trasmissione di dati a un dispositivo I2C servant presso l’indirizzo specificato. I dati sono messi in coda per la trasmissione utilizzando la funzione
write() e poi vengono endTransmission().
effettivamente trasmessi utilizzando la funzione
endTransmission()
Trasmette i byte che sono stati messi in coda da write() a un dispositivo servant e quindi pone fine a una trasmissione che è stata iniziata da beginTransmission().
write()
Scrive i dati forniti a una coda per la trasmissione da un dispositivo master a uno servant, oppure da un dispositivo servant a uno master in risposta a una richiesta di dati. Restituisce il numero di byte scritti nella cosa.
available()
Restituisce il numero di byte disponibili per la funzione read(). Chiamata da un dispositivo master dopo una chiamata a requestFrom() e su un dispositivo servant dopo un evento di ricezione di dati.
read()
Legge un byte che è stato trasferito da master a servant o viceversa.
onReceive()
Registra la funzione da chiamare (una funzione handler) quando un dispositivo servant riceve dati da un master.
onRequest()
Registra la funzione da chiamare quando un master richiede dati da un dispositivo servant.
Esplora La libreria Esplora di Arduino offre una serie di funzioni per interfacciarsi facilmente con i
sensori e gli attuatori della scheda Esplora per mezzo della classe Esplora. Trovare maggiori informazioni sul pinout nel Capitolo 4. I sensori disponibili sulla scheda sono: •
Joystick analogico a due assi
•
Pulsante a pressione centrale del joystick
•
Quattro pulsanti a pressione
•
Microfono
•
Sensore di luminosità
•
Sensore di temperatura
•
Accelerometro a tre assi
•
Due connettori di input TinkerKit
Gli attuatori disponibili sulla scheda sono: •
LED RGB (Red-Green-Blue) alta luminosità
•
Cicalino piezo
•
2 connettori di output TinkerKit output
Esplora()
Crea un’istanza di un oggetto Esplora.
readSlider()
Restituisce un valore intero che corrisponde alla posizione corrente del controllo cursore. Il valore può essere compreso tra 0 e 1023.
readLightSensor()
Restituisce un valore intero che corrisponde alla quantità di luce che tocca il sensore di luminosità della scheda Esplora.
readTemperature()
Restituisce un intero con segno con la temperatura corrente dell’ambiente espressa in Fahrenheit oppure Celsius. L’argomento scale accetta sia DEGREES_C sia DEGREES_F. Gli intervalli di temperatura sono da –40C a 150C e da –40F a 302F.
readMicrophone()
Restituisce un valore intero che corrisponde alla quantità di rumore d’ambiente rilevato dal microfono. Il valore restituito può essere compreso tra 0 e 1023.
readJoystickSwitch()
Legge il pulsante del joystick e restituisce 0 oppure 1023. Un’alternativa è la funzione read JoystickButton().
readJoystickButton()
Legge il pulsante del joystick e restituisce LOW oppure HIGH (premuto o non premuto). Questa funzione si comporta esattamente come readJoystickSwitch(), ma restituisce un valore consistente con la funzione readButton().
readJoystickX()
Restituisce la posizione sull’asse x del joystick, nella forma di un valore compreso tra –512 e 512.
readJoystickY()
Restituisce la posizione sull’asse y del joystick, nella forma di un valore compreso tra –512 e 512.
readAccelerometer()
Restituisce il valore corrente di un asse selezionato e i valori possibili per l’argomento axis sono X_AXIS, Y_AXIS e Z_AXIS. Se il valore restituito è 0, significa che l’accelerometro è perpendicolare alla direzione della gravità, mentre valori positivi o negativi indicano la direzione e la velocità dell’accelerazione.
readButton()
Legge lo stato corrente di un determinato pulsante della Esplora. Restituisce un valore low (false) se il pulsante è premuto, oppure un valore high (true) in caso contrario.
writeRGB()
Scrive una serie di valori che definiscono i livelli di luminosità degli elementi rosso,
verde e blu del LED RGB della Esplora.
writeRed()
Accetta un argomento che definisce la luminosità del LED rosso con un intervallo che va da 0 a 255.
writeGreen()
Accetta un argomento che definisce la luminosità del LED verde con un intervallo che va da 0 a 255.
writeBlue()
Accetta un argomento che definisce la luminosità del LED blu con un intervallo che va da 0 a 255.
readRed()
Restituisce l’ultimo valore utilizzato per impostare la luminosità del LED rosso.
readGreen()
Restituisce l’ultimo valore utilizzato per impostare la luminosità del LED verde.
readBlue()
Restituisce l’ultimo valore utilizzato per impostare la luminosità del LED blu.
tone()
Emette un tono con l’annunciatore integrato sulla scheda Esplora a una frequenza data. Se non è fornito nessun argomento duration, il tono continua finché non viene chiamata la funzione noTone(). Può essere utilizzata soltanto una frequenza alla volta. Notate che l’utilizzo della funzione tone() interferisce con il controllo del livello del LED rosso.
noTone()
Termina l’output del segnale a onde quadre dell’annunciatore.
Le librerie USB Le librerie USB permettono a un Arduino Leonardo o Micro di apparire come un mouse e/o una tastiera agli occhi del computer host. NOTA Se la libreria Mouse o Keyboard è sempre attiva, programmare Arduino diventa difficile. Funzioni come Mouse.move() e Keyboard.print() devono essere chiamate soltanto quando l’host è pronto per gestirle. Un modo per risolvere questo problema è utilizzare un sistema di controllo oppure un interruttore fisico per controllare quando Arduino deve emettere i messaggi mouse o keyboard.
Mouse Le funzioni mouse permettono a una scheda Leonardo o Micro di controllare il movimento del cursore su un computer host. La posizione del cursore riportata è sempre relativa alla sua posizione precedente: non è assoluta.
Keyboard Le funzioni keyboard permettono a una scheda Leonardo o Micro di inviare pressioni di tasti a un computer host collegato. Anche se con la libreria Keyboard non è possibile inviare tutti i caratteri ASCII possibile, e in particolare quelli che non vengono stampati, la libreria supporta l’utilizzo dei tasti modificatori.
I tasti modificatori cambiano il comportamento di un altro tasto quando vengono premuti simultaneamente. La Tabella 7-1 elenca i tasti modificatori supportati dalla scheda Leonardo. Tabella 7-1 - I tasti modificatori della tastiera USB.
Tasto
Valore esadecimale
Valore decimale
Tasto
Valore esadecimale
KEY_LEFT_CTRL
0x80
128
KEY_PAGE_UP
0xD3
KEY_LEFT_SHIFT
0x81
129
KEY_PAGE_DOWN
0xD6
KEY_LEFT_ALT
0x82
130
KEY_HOME
0xD2
KEY_LEFT_GUI
0x83
131
KEY_END
0xD5
KEY_RIGHT_CTRL
0x84
132
KEY_CAPS_LOCK
0xC1
KEY_RIGHT_SHIFT
0x85
133
KEY_F1
0xC2
KEY_RIGHT_ALT
0x86
134
KEY_F2
0xC3
KEY_RIGHT_GUI
0x87
135
KEY_F3
0xC4
KEY_UP_ARROW
0xDA
218
KEY_F4
0xC5
KEY_DOWN_ARROW
0xD9
217
KEY_F5
0xC6
KEY_LEFT_ARROW
0xD8
216
KEY_F6
0xC7
KEY_RIGHT_ARROW
0xD7
215
KEY_F7
0xC8
KEY_BACKSPACE
0xB2
178
KEY_F8
0xC9
KEY_TAB
0xB3
179
KEY_F9
0xCA
KEY_RETURN
0xB0
176
KEY_F10
0xCB
KEY_ESC
0xB1
177
KEY_F11
0xCC
KEY_INSERT
0xD1
209
KEY_F12
0xCD
Altre librerie Esistono molte altre librerie disponibili per le schede Arduino. Alcune sono state create da individui, altre da società che vendono e supportano hardware e accessori per Arduino. Inoltre, alcuni distributori forniscono anche librerie o software di supporto per i loro prodotti e questo codice spesso si trova cercandolo sul sito web adatto oppure su eBay. Le Tabelle dalla 7-2 alla 7-8 elencano una selezione di queste librerie, suddivise in categorie. Le descrizioni sono necessariamente brevi: è davvero impossibile descriverle tutte in modo sufficiente da rendere loro giustizia mantenendo il libro in un formato compatto. Trovate i link per maggiori dettagli su http://www.arduino.cc/en/Reference/Libraries. Tabella 7-2 - Comunicazione (reti e protocolli).
Libreria
Descrizione
Messenger
Per elaborare messaggi di testo provenienti dal computer
NewSoftSerial
Una versione migliorata della libreria SoftwareSerial
OneWire
Per controllare dispositivi (di Dallas Semiconductor) che utilizzano il protocollo One Wire
PS2Keyboard
Per leggere caratteri provenienti da una tastiera PS2
Simple Message System
Per inviare messaggi tra Arduino e il computer
SSerial2Mobile
Per inviare messaggi di testo o email utilizzando un telefono cellulare (con comandi AT via SoftwareSerial)
Webduino
Una libreria server web che si può estendere (da utilizzare con la shield Ethernet di Arduino)
X10
Per inviare segnali X10 su linee di alimentazione AC
XBee
Per comunicare con XBee in modalità API
SerialControl
Per controllare in remoto altre schede Arduino per mezzo di un collegamento seriale
Tabella 7-3 - Percezione.
Libreria
Descrizione
Capacitive Sensing
Per convertire due o più pin in sensori capacitivi
Debounce
Per leggere input digitali con disturbo (per esempio provenienti da pulsanti)
Tabella 7-4 - Display e LED.
Libreria
Descrizione
GFX
Classe di base con routine grafiche standard (di Adafruit Industries)
GLCD
Routine grafiche per LCD basate su chipset KS0108 o equivalente
LedControl
Per controllare matrici di LED o display a 7 segmenti con un MAX7221 o un MAX7219
LedControl
Un’alternativa alla libreria Matrix per gestire diversi LED con chip Maxim
LedDisplay
Per controllare un display di LED scorrevole HCMS-29xx
Matrix
Libreria di base per manipolare matrici di LED
PCD8544
Per il controller LCD su dispositivi di tipo Nokia 55100 (di Adafruit Industries)
Sprite ST7735
Libreria di base per manipolare immagini sprite da utilizzare con una matrice di LED Per il controller LCD su uno schermo TFT 1,8”, 128 × 160 pixel (di Adafruit Industries)
Tabella 7-5 - Audio e forme d’onda.
Libreria
Descrizione
FFT
Per analizzare la frequenza di audio o altri segnali analogici
Tone
Per generare onde quadre di frequenze audio sullo sfondo su un pin del microcontroller
Tabella 7-6 - Motori e PWM.
Libreria TLC5940
Descrizione Per controllare il TLC5940 IC, un’unità PWM da 16 canali e 12 bit
Tabella 7-7 - Timing.
Libreria
Descrizione
DateTime
Una libreria per tenere traccia di data e ora correnti nel software
Metro
Aiuta a temporizzare azioni a intervalli regolari
MsTimer2
Utilizza l’interrupt del timer 2 per lanciare un’azione ogni N millisecondi
Tabella 7-8 - Utility.
Libreria
Descrizione
PString
Una classe leggera per stampare sui buffer
Streaming
Una libreria che semplifica le dichiarazioni di stampa
8 Le shield
Una shield Arduino è una scheda a circuito aggiuntiva progettata per lavorare con i connettori che si trovano sulle schede Arduino standard come la Uno, la Duemilanove, la Leonardo, oppure la Mega. Le shield sono dotate di pin che si interfacciano con Arduino in modo che l’alimentazione, gli I/O digitali, quelli analogici e così via diventino disponibili per la shield. Questo capitolo descrive alcune delle shield compatibili con Arduino che esistono sul mercato, mentre il Capitolo 10 descrive il processo di creazione di una shield personalizzata. Esistono shield pensate per una vasta gamma di applicazioni, da schede essenziali per la proptotipazione a controllori di motori, interfacce Ethernet, memorie flash SD e display. Molte shield possono essere collegate una sopra l’altra, permettendo a una scheda Arduino di base di interfacciarsi contemporaneamente con due o più shield. NOTA Questo capitolo menziona molti distributori e produttori, ma non con l’intenzione di consigliarne qualcuno in particolare. Le shield mostrate qui semplicemente rappresentano quello che avete a disposizione e per ciascun tipo probabilmente potete trovare distributori diversi che vendono lo stesso prodotto o uno equivalente. Potete sentirvi liberi di acquistarle dove preferite.
Questo capitolo non è assolutamente un elenco completo di tutti i vari tipi di shield che avete a vostra disposizione. Esiste un settore di produzione a domicilio specializzato nella creazione di nuove variazioni di shield esistenti e di tipi nuovi che non si sono mai visti prima. La selezione di shield descritta qui è ampiamente rappresentativa di quello che esiste e qui trovate i link necessari se volete saperne di più o magari acquistare una shield o due. In alcuni casi, ho incluso informazioni più dettagliate rispetto a quelle che forniscono i distributori (o che non forniscono proprio, in alcuni casi), ma questo non significa che io sia particolarmente affezionato a una shield in particolare. Semplicemente, sono affezionato alla documentazione e quindi sono solito cercarla per procedere con quello che voglio fare. Anche voi potete trovarvi nella situazione di possedere una shield che sembra davvero utile ma per la quale non esiste quasi o del tutto documentazione o per la quale esiste soltanto in cinese (o in qualche altra lingua che magari non conoscete). Spero che questo capitolo vi aiuti a riempire alcuni di questi vuoti, o almeno che vi offre una vaga idea di dove andare a cercare. SUGGERIMENTO Alcune delle shield mostrate qui non sono più disponibili presso i distributori originali, ma possono essere acquistate da altre parti. Quasi tutti i distributori forniscono link attivi alla documentazione e quindi, se trovate una shield che sembra simile alla vostra (dopo tutto si tratta di hardware open source), spesso riuscite a ottenere le
informazioni tecniche che vi servono.
Quando si cerca una shield, una cosa da ricordare è che alcuni sembrano non avere ben chiaro che cos’è una shield. Non è un modulo con una riga di pin su un lato (come quelli che vedremo nel Capitolo 9). Una shield è una scheda con le caratteristiche fisiche descritte in “Le caratteristiche fisiche delle shield” a pagina 221. Tutto il resto può essere considerato un modulo e i moduli possono collegarsi direttamente o meno ad Arduino (di solito non si collegano semplicemente, ma hanno bisogno di fili elettrici di qualche tipo che conducano l’alimentazione e i segnali ai pin adatti sulla scheda Arduino).
Le caratteristiche elettriche delle shield Se confrontare i diagrammi dei pinout delle varie shield presentate in questo capitolo, potete notare un modello regolare: le shield che utilizzano un’interfaccia a due fili (l’interfaccia TWI o I2C) utilizzano sempre i pin A4 e A5 di Arduino. Su una scheda di tipo base (Diecimila, Duemilanove e Uno R2 o SMD), questi si trovano sul connettore I/O analogico, mentre sul layout esteso delle schede più recenti (Uno R3, Ethernet, Leonardo), i segnali appaiono anche sulle estensioni dei pin-header (nell’angolo in alto accanto al connettore USB o RJ45). Una shield che utilizza I2C può utilizzare una qualsiasi delle serie di pin e potete dare per scontato che A4 e A5 non saranno disponibili per altri usi senza intervenire con la programmazione. Per lo stesso motivo, le shield che utilizzano l’interfaccia SPI di solito utilizzano i pin D10, D11, D12 e D13 (SS, MOSI, MISO e SCK, rispettivamente). L’utilizzo di D10 come pin select è opzionale e per questo scopo alcune shield utilizzano un pin digitale diverso. Ricordate che con SPI, per poter accettare i dati provenienti dal dispositivo master, ciascun dispositivo “slave” deve essere selezionato esplicitamente con un segnale select. Le shield con più di un dispositivo SPI collegato possono anche utilizzare più di un pin I/O digitale come segnale select. Le shield che utilizzano UART (o USART, come lo chiama Atmel) di solito utilizzano i pin D0 e D1 (Rx e Tx, rispettivamente, oppure RxD0 e TxD0 sulle schede Arduino di tipo Mega). Alcune shield Bluetooth utilizzano l’interfaccia UART per comunicare con un modulo Bluetooth, come la shield di interfaccia RS-232 e la RS-485. Poi esistono shield che utilizzano quasi tutti i pin di Arduino. La shield DIY multifunzione descritta in “Shield varie” a pagina 273 funziona così, ma è dotata di pin per collegarsi a segnali che non sono utilizzati specificamente sulla scheda (tre digitali e uno analogico, in questo caso). In generale, potete tranquillamente dare per scontato che le shield di estensione I/O utilizzano la maggior parte o tutti i pin disponibili di Arduino e che le shield che supportano qualcosa come per esempio un display generalmente non sono dotate di nessun punto di collegamento per accedere ai segnali che non si utilizzano. Per questo motivo, questi tipi di shield di solito non possono accoglierne un’altra sopra di esse e devono essere posizionate in cima a una pila di shield su Arduino.
Quasi tutte le shield non presentano circuiti estremamente complicati, ma sono cose relativamente semplici basate su IC esistenti oppure su componenti di un qualche tipo. Come le schede Arduino, essenzialmente sono contenitori per alcuni tipi di IC, relè e così via. Le caratteristiche elettriche di una shield sono quelle del chip o dei componenti sui quali si basa. Questa semplicità è quello che contribuisce a mantenere basso il costo di una shield, mentre le funzionalità degli IC o dei componenti che utilizza sono quello che la rende utile. Infine, alcune shield possono mettere in un buffer i segnali diretti a o provenienti da Arduino, utilizzando circuiti attivi oppure dispositivi come isolatori ottici o relè, ma la maggior parte di loro serve semplicemente da posto per montare connettori o componenti, come le shield di estensione mostrate in “Shield di estensione I/O” a pagina 226, che utilizzano connettori multipin. Le connessioni, che siano socket-header oppure pin-header sono semplicemente estensioni dei pin di Arduino e non c’è niente che prevenga dal rischio di collegare 12 volt a un input digitale da 5 V (o addirittura da 3,3 V) e convertire il microcontroller AVR di Arduino in un pezzo di carbone. Per questo, è necessario fare sempre attenzione al voltaggio e controllare i limiti di tensione del microcontroller AVR.
Le caratteristiche fisiche delle shield Dal punto di vista fisico, una tipica shield è grande come una scheda Arduino di base (ne trovate le dimensioni nel Capitolo 4) e può presentare la stessa lunghezza di Arduino, oppure essere più lunga o più corta. È possibile creare una shield più ampia di una scheda Arduino di base, dal momento che l’unico limite reale è il fatto che i pin della shield devono potersi allineare con i pin socket della scheda Arduino sottostante (ne trovate posizioni e dimensioni nel Capitolo 4). Installare una shield non comporta nient’altro che collegarla come mostra la Figura 8-1.
Figura 8-1 - Come si monta una shield su una scheda Arduino host.
Le schede Arduino più recenti, che utilizzano il layout dei pin R3, sono dotate di due pin socket al termine di ciascuna riga, che non sono utilizzate dalla shield. Questo non è importante, dal momento che queste prese extra o sono duplicati di pin esistenti oppure non sono collegate. Nel caso delle schede Mega, la shield si monta come mostra la Figura 4-20 nel Capitolo 4, dove la maggior parte dei pin della scheda Mega non sono collegati alla shield e alcuni altri sono resi inaccessibili dalla PCB della shield sottostante. Tutti i pin e i segnali di base sono a disposizione della shield. SUGGERIMENTO Bisogna sempre controllare l’isolamento tra i componenti della scheda Arduino di base e la PCB della shield. In alcuni casi, un connettore USB o un jack RJ45 può interferire con la shield e potenzialmente causare un corto circuito.
A volte, potete riscontrare un problema con alcune parti della scheda Arduino che toccano le tracce o le piazzole del circuito che si trovano sulla parte posteriore di una shield. Per isolare il contatto potete utilizzare un pezzettino di nastro isolante o addirittura un pezzo di carta spessa, ma il modo migliore di risolvere questo problema è utilizzare dei distanziatori o degli standoff per separare fisicamente le due schede. Questi possono essere piccoli tubi di metallo o di nylon (di una lunghezza compresa tra 7/16 e 1/2 di pollice, circa 11/12 mm) con un foro centrale sufficiente per una vite a testa tonda (che tipicamente è di tipo 2-56 SAE, oppure di una dimensione simile). La
differenza tra uno standoff è un distanziatore è semplice: gli standoff hanno filettature interne, i distanziatori no. Un distanziatore o uno standoff serve per alzare la scheda superiore abbastanza da prevenire cortocircuiti, come mostra la Figura 9-3 nel Capitolo 9. Inoltre, permette di bloccare meccanicamente in modo solido due o più schede. Quando si montano una sopra l’altra due o più shield su un Arduino, si può decidere di utilizzare viti a testa tonda lunghe con distanziatori, oppure si può scegliere di utilizzare un tipo di standoff con proiezione di tipo vite su un’estremità e un foro filettato sull’altra estremità. Questi, noti anche come “martinelli a vite”, si trovano spesso sui PC e, se mai avete assemblato il vostro computer a partire da zero, li avete già visti. La Figura 8-2 mostra alcuni esempi dei tipi di distanziatori e di standoff disponibili. Questi componenti possono essere fatti di nylon, allumino, acciaio inossidabile, ottone o plastica.
Figura 8-2 - Tipi di distanziatori e standoff.
I distanziatori possono anche essere ricavati da strisce ritagliate da PCB di prototipazione e fatte scivolare tra i pin della scheda superiore. Questa tecnica non serve molto per la connessione fisica delle schede, ma aggiunge spazio sufficiente per prevenire collisioni. Potete acquistare distanziatori e standoff presso vari distributori, come Amazon (http://amazon.com/), McMaster-Carr (http://www.mcmaster.com/), Mouser (http://www.mouser.com/) e Digi-Key (http://www.digikey.com/). Se per caso nella vostra città è presente una ferramenta, qui vi potete trovare questi prodotti e altre cose utili (come viti a testa tonda e dadi 1-72 o 2-56).
Montare diverse shield una sopra l’altra A volte, non ha senso utilizzare terminali pin socket estese per far stare una shield su una pila. Se, per esempio, una shield ha un grande numero di connettori che richiedono accesso verticale, semplicemente non c’è spazio sufficiente per montarvi sopra un’altra shield. Ma a volte potete imbattervi in una shield che può essere montata su un’altra ma non è dotata dei tipi di connettori corretti. Di solito, per permettere a una shield di essere montata su un’altra, si utilizzano due tecniche: socket con pin estesi oppure pin e socket spostati. L’approccio dei pin estesi permette alla shield di allinearsi verticalmente. L’altro design produce shield una sopra l’altra che sono spostate della distanza tra le righe di pin e di socket. Se le shield si spostano tutte nello stesso modo, il risultato può avere l’aspetto di una scala e i fori delle viti di montaggio sulle schede non si allineano correttamente. L’uso di pin estesi richiede socket con pin lunghi per il montaggio su una PCB. I pin più lunghi sulla parte posteriore (quella delle saldature) della shield si inseriscono nei socket di Arduino e un’altra shield può essere montata in cima. La tecnica dello spostamento utilizza pin-strip separate per collegare la shield a Arduino e socket-strip separate per accettare un’altra shield. Queste vengono montate una di fianco all’altra, di solito più vicino possibile per ridurre al minimo lo spostamento tra le shield.
Shield Arduino comuni I questo paragrafo vedremo alcuni dei tipi più comuni di shield. Non è assolutamente un elenco esaustivo, dal momento che continuamente ne appaiono di nuove e ne vengono abbandonate di vecchie o che altrimenti possono non essere più disponibili. In quest’era di prototipazione rapida, improvvise inversioni di tendenza e produzione a basso costo, una shield può apparire e poi scomparire soltanto pochi mesi dopo. Per rimanere al passo con quello che esiste, potete consultare gli elenchi dei distributori cinesi su eBay e quelli di Amazon.com, Adafruit, SparkFun, SainSmart e altri siti web. Nell’Appendice C trovate fonti note di shield Arduino. La Tabella 8-2 che si trova al termine di questo capitolo elenca i distributori e produttori dei quali parliamo qui. Ecco un elenco che rappresenta un riferimento rapido delle shield descritte qui, suddivise in categorie: •
Input/output – Shield d’estensione I/O – Shield d’espansione I/O – Relè shield – Shield che trasportano il segnale
•
Memoria – Schede di memoria flash SD e microSD
•
Comunicazione – I/O seriale – MIDI – Ethernet – Bluetooth – USB – ZigBee – CAN
•
Prototipazione
•
Controllo del movimento – Controllo di motori passo-passo e DC – Controllo di PWM e servo
•
Display – Array di LED – Display di LED a 7 segmenti – Display LCD – Display TFT a colori
•
Shield per la strumentazione – Registrazione di dati – Analizzatore logico – ADC da 24 bit – ADC da 12 bit
•
Shield adattatore – Adattatori Nano – Adattatori morsettiera
•
Shield varie – Morsettiera/prototipazione – Shield multifunzione
In questo paragrafo, daremo anche una rapida occhiata ad alcune shield meno comuni
progettate per applicazioni specifiche: un’interfaccia di controllo di un incisore CNC, un’interfaccia di controllo di una RepRap e un game controller FPGA.
Input/Output Esistono shield input/output (I/O) che collegano vari pin I/O di Arduino ai connettori che sono più robusti dei pin del circuito della scheda Arduino (oppure, nel caso dell’Arduino Nano, i pin sotto la scheda sono collegati a connettori tipo morsettiera su un contenitore per la PCB della Nano). Le shield I/O possono essere ampiamente classificate come shield d’estensione oppure come shield d’espansione, anche se il termine “shield d’espansione” spesso viene applicato a entrambi i tipi. Una shield d’estensione collega i pin I/O di un Arduino senza alterarne i segnali: semplicemente utilizza tipi diversi di connettori. Una shield d’espansione vera e propria, invece, utilizza componenti elettronici attivi per aumentare il numero di canali I/O digitali discreti. Per comunicare con la scheda Arduino host, questi tipi di shield utilizzano SPI o I2C.
Shield di estensione I/O Questa categoria di shield si utilizza per condurre i segnali input/output dal chip AVR ai connettori che sono più robusti dei pin socket utilizzate sulle schede Arduino. Alcune shield d’estensione I/O possono offrire un buffering attivo di qualche tipo, ma la maggior parte si limitano a portare i segnali della scheda Arduino. A volte, vengono dette shield d’espansione, ma non è del tutto corretto, dal momento che si limitano a trasferire i segnali esistenti da un connettore di Arduino a un altro sulla shield. La shield per sensori di SainSmart (http://bit.ly/sainsmart-sensor-shield) Si tratta di una shield che si può montare con altre (notate lo spostamento tra le pinstrip e le socket strip nella Figura 8-3). Gli I/O dell’AVR sono portati fuori da socket multi-pin, blocchi di pin-header e posizioni per due header da 10 pin adatti per essere utilizzati con connettori con cavo a nastro di tipo IDC. È fornito anche un interruttore di reset. Questa shield può essere utilizzata con qualsiasi scheda Arduino con la configurazione di base dei pin, comprese le schede Mega.
Figura 8-3 - La shield d’espansione I/O di SainSmart (interfaccia per sensori).
La Figura 8-4 illustra i grandi connettori modulari sui bordi della PCB della shield. Questi sono connettori multipin, a volte detti conntettori “buckled”, che si adattano alle spine corrispondenti di tre e quattro pin. I cavi multiconduttori sono comuni e possono essere trovati presso diversi rivenditori. Uno (diverso da SainSmart) è TrossenRobotics (http://bit.ly/trossen-robotgeek).
Figura 8-4 - Il layout dei pin e dei connettori della shield d’espansione I/O di SainSmart.
La shield per sensori di TinkerKit (http://bit.ly/tinkerkit-sensor) Questa shield che si può montare con altre (Figura 8-5) utilizza prese di pin con terminali lunghi, 12 connettori da tre pin e due connettori da quattro pin. Tra i connettori da quattro pin si trova un interruttore di reset.
Figura 8-5 - La shield d’espansione I/O di TinkerKit.
In origine, la shield per sensori di TinkerKit era stata progettata per lavorare con vari moduli sensore e motore prodotti da TinkerKit, ma può essere utilizzata come qualsiasi altra shield d’estensione I/O. La Figura 8-6 mostra il layout dei connettori sulla PCB. Questi utilizzano uno schema a tre fili come quello utilizzato sulla scheda di SainSmart che abbiamo mostrato prima. Per maggiori dettagli sui moduli TinkerKit progettati per essere utilizzati con questa shield, potete consultare il Capitolo 9.
Figura 8-6 - I connettori della shield d’espansione I/O di TinkerKit.
Anche se attualmente TinkerKit non è attiva, i suoi prodotti si trovano ancora presso Mouser (http://www.mouser.com/) e altri rivenditori. Le librerie software sono disponibili su GitHub (https://github.com/TinkerKit). La shield per sensori per Mega di TinkerKit (http://bit.ly/tinkerkitmega-sensor) La shield per sensori per Mega di TinkerKit (Figura 8-7) è progettata per collegare i pin I/O addizionali delle schede Arduino Mega, Mega2650 o Mega ADK. Utilizza prese di pin a terminali lunghi per permettere di montarle una sopra l’altra e sulla PCS è fornito un interruttore di reset. Essenzialmente si tratta di una versione più grande della shield di TinkerKit descritta prima.
Figura 8-7 - La shield d’espansione I/O di TinkerKit per le schede Arduino di tipo Mega.
La shield Grove Base Un sistema di moduli e di shield che sta guadagnando popolarità tra gli utenti di Arduino sono i componenti Grove venduti da Seeed Studio. Si tratta di un ampia varietà di moduli da scegliere ed è disponibile una scheda di base con integrata una MCU ATMEGA328p compatibile con Arduino. La scheda, progettata da Linaro.com (96Boards.org), è mostrata nella Figura 8-8.
Figura 8-8 - La shield Grove Base.
Seeed Studio vende anche una shield d’espansione passiva (cioè priva di MCU integrata) per il sistema di moduli Grove, ma, anche se potete riuscire ancora a trovarne qualcuna, non sono più sviluppate. La shield Passive Seeed Studio Grove Base è mostrata nella Figura 8-9. Per ulteriori informazioni sulla serie di moduli Grove e le shield di interfaccia compatibili, potete visitare la wiki di Seeed Studio (http://bit.ly/seeed-grove).
Figura 8-9 - La shield Seeed Studio Passive Grove Base.
La shield d’espansione per sensori di CuteDigi (http://bit.ly/cutedigi) Tecnicamente, si tratta di una shield d’estensione I/O, più che di una shield d’espansione vera e propria. Per portare i segnali delle schede Arduino di tipo Mega, questa shield di CuteDigi (Figura 8-10) utilizza header di pin anziché connettori. Non permette di montare su di essa un’altra shield, ma, vista la distribuzione verticale dei pin sulla PCB, non avrebbe senso montare qualcosa su questa scheda. Le etichette sulla PCB sono chiare e le funzioni ovvie. Questa shield è interessante per il fatto che include anche un header con pin ad angolo retto per collegarsi a un lettore di schede flash di tipo SD e un header di pin da utilizzare con un modulo Bluetooth. I connettori adottano lo stesso schema S-V-G (signal, V+, ground) che si trova su altre shield d’estensione I/O.
Figura 8-10 - La scheda d’estensione per Mega di CuteDigi con le connessioni flash SD e Bluetooth.
Shield d’espansione I/O A differenza delle shield d’estensione I/O elencate nel paragrafo precedente, una shield d’espansione I/O offre ulteriori funzionalità I/O, di solito nella forma di I/O digitali discreti (anche se alcune shield presentano capacità analoghe). Dal momento che queste shield sono dotate di circuiti attivi oltre a vari connettori, sono più care di quelle d’estensione. Il grande vantaggio che offrono è rappresentato dal fatto che mettono a disposizione diversi canali I/O utilizzando soltanto una connessione I2C o SPI con la scheda Arduino sottostante. Questo lascia i pin rimanenti di Arduino a disposizione per altre applicazioni. La shield Centipede di Macetech (http://bit.ly/macetech-centipede) La shield Centipede di Macetech (Figura 8-11) utilizza l’interfaccia I2C di Arduino per fornire 64 pin I/O digitali discreti a scopo generale. I pin sono organizzati in 4 gruppi di 16 pin, con ciascun gruppo controllato da un chip di espansione I/O I2C. La Figura 8-12 mostra il layout dei pin I/O utilizzato sulla shield di Macetech. Ciascuno degli IC MUX (multiplexer) controlla 16 pin, oppure un blocco di pin I/O. Notate come è organizzata la numerazione dei pin su ciascun blocco, con la numerazione “avvolta” intorno al blocco.
Figura 8-11 - La shield d’espansione I/O Centipede di Macetech.
Figura 8-12 - Il layout dei pin della shield I/O Centipede di Macetech.
La shield d’espansione I/O di LinkSprite (http://bit.ly/linksprite)
Si tratta di una shield che si può montare con altre e che utilizza un chip d’espansione I/O I2C MCP23017 per fornire 16 ulteriori pin I/O digitali discreti (Figura 8-13). Notate che questa shield è progettata per utilizzare schede Arduino in stile R3 e che utilizza gli ultimi due pin (9 e 10, SDA e SCL) del connettore esteso che si trova sulle schede Uno R3 e Leonardo. I pin I/O espansi sono sistemati in due serie di otto canali discreti, che si chiamano GPIOA e GPIOB. Come mostra la Figura 8-14, questi sono posizionati accanto alle strisce di prese di pin I/O digitali. Questo rende scomodo utilizzare questi pin se su questa è montata un’altra shield, per cui bisogna fare attenzione alle peculiarità di questo tipo. Se invece è l’unica shield che si sta utilizzando, oppure quella che sta al di sopra di tutte le altre, non dovrebbero esserci problemi.
Figura 8-13 - La shield d’espansione I/O a 16 canali di CuteDig.
Figura 8-14 - Il layout dei pin della shield d’espansione I/O a 16 canali di CuteDig.
La shield d’espansione I/O digitale e analogico di Numato (http://bit.ly/numatodigitalanalog) La shield d’espansione digitale e analogico di Numato (Figura 8-15) mette a disposizione 28 ulteriori canali I/O digitali discreti e 16 input analogici utilizzando due chip I/O I2C MCP23017 e un IC multiplexer analogico NXP 74HC4067 per i segnali analogici.
Figura 8-15 - La shield d’espansione I/O digitale e analogico di Numato.
Come mostra la Figura 8-16, l’interfaccia principale con Arduino è l’interfaccia I2C sui pin A4 e A5. I pin interrupt dei chip MCP23017 sono anch’essi collegati ai blocchi di pin I/O digitali. I sei pin header al centro della scheda si utilizzano con blocchi di jumper per selezionare gli indirizzi I2C dei due chip MCP23017.
Figura 8-16 - Il layout dei pin della shield d’espansione I/O di Numato.
Relè shield Le relè shield sono disponibili con uno o più relè. I relè utilizzati in queste shield possono essere da 5 o da 10 ampere come quelli mostrati sulle shield elencate qui, oltre che i relè reed dei package DIP. NOTA Quando dovete scegliere una scheda relè, dovete fare attenzione a notare la valutazione massima della shield suggerita dal rivenditore. I relè modulari che si utilizzano su una shield possono essere dotati di contatti nominalmente per AC da 10 A a 120 V, ma i connettori e le tracce della PCB della shield PCB possono non essere indicati per questo livello di teensione. Notate anche che non tutti i rivenditori riducono la capacità tenendo conto dei limiti dei connettori delle PCB. Conviene prendersi un momento e controllare le specifiche del relè basandosi sul numero del componente mostrato nelle foto o negli schemi del rivenditore. Pensateci due volte, prima di procurarvi una shield dove i numeri dei componenti sono stati rimossi o nascosti in qualche altre modo (e questo vale per qualsiasi shield, non soltanto per le relè shield).
La relè shield di DFRobot (http://bit.ly/dfrobot-relay) Questa shield mostra come il fattore di forma di una shield può essere “modificato” per adattarla a componenti più grandi. Nel caso della relè shield di DFRobot (Figura 8-17), i quattro relè sono montati su un componente espanso della PCB della shield. I contatti dei relè hanno 3 A nominali a DC da 24 V o AC da 120 V, con una capacità di tensione massima di 5 A. Si tratta di una shield che può essere montata con altre, anche se i pin I/O verticali possono rendere difficile utilizzare un’altra scheda sopra questa.
Figura 8-17 - La relè shield di DFRobot.
La scheda utilizza una serie di jumper per portare i segnali digitali per i driver dei relè
e i pin di un modulo XBee, mostrato nella Figura 8-18. Tutti i pin digitali e analogici di Arduino sono collegati in blocchi di pin header.
Figura 8-18 - Il layout della relè shield di DFRobot.
La relè shield di Numato (http://bit.ly/numato-relay) Questa shield (Figura 8-19) utilizza due relè modulari a basso consumo con contatti da 1 A ad AC 120 V e 2 A a DC 24 V. La shield di Numato utilizza i pin digitali di Arduino 2 e 3. I terminali dei relè sono collegati a delle morsettiere. Si tratta di una shield che può essere impilata sulle altre.
Figura 8-19 - La relè shield di Numato.
La relè shield di Seeed Studio (http://bit.ly/seeedstudio-relay) La relè shield di Seeed Studio (Figura 8-20) utilizza quattro relè con contatti da 10 A ad AC 120 V. Utilizza i pin di output digitale di Arduino dal 4 al 7, uno per relè. Ciascun relè è dotato di un LED che ne indica l’attività. Si tratta di una shield che può essere montata con altre.
Figura 8-20 - La relè shield di Seeed Studio.
Shield che trasportano il segnale
Non ne esistono moltissime. Di solito, quelle che si trovano sono di due tipi: routing passivo oppure routing MUX (multiplexer) attivo. La patch shield di Adafruit (http://www.adafruit.com/products/256) Una patch board è una board d’interconnessione messa a disposizione da Adafruit e mostrata nella Figura 8-21 permette di connettere i segnali tra quattro connettori di tipo RJ45 (noti anche come connettori 8P8C) e la scheda Arduino sottostante utilizzando fili patch corti inseriti in blocchi di pin socket.
Figura 8-21 - La patch shield di Adafruit.
NOTA Questo è un kit, non una shield assemblata. La foto mostra come deve presentarsi la shield assemblata.
L’idea principale che sta dietro la patch shield è portare determinati segnali a e da un Arduino per mezzo di cavi Ethernet convenzionali a punti di connessione remoti, come mostra la Figura 8-22. Il kit include quattro PCB satellite con jack 8P8C (RJ45) e pin per collegarsi a una breadboard che non richiede saldature, un modulo sensore, oppure un’altra scheda Arduino. Su questa shield o sulle schede satellite non ci sono componenti attivi: si limitano semplicemente a trasportare segnali.
Figura 8-22 - Il layout e l’uso della patch shield di Adafruit.
La shield Go-Between di Mayhew Labs (http://bit.ly/mayhew-gobtw) La shield Go-Between (Figura 8-23) utilizza una matrice di posizioni di jumper saldabili per portare i segnali dall’Arduino di base o da una shield più in basso a una shield più in alto. Può rivelarsi utile quando volete mettere una sopra l’altra due shield che utilizzano gli stessi pin per le funzioni I/O. Se i pin della shield superiore possono essere spostati su pin diversi sulla shield inferiore senza dover apportare modifiche, questo risolve il problema. Tutto funzionerà con una piccola modifica del software.
Figura 8-23 - La shield Go-Between di Mayhew Labs.
La Mux Shield II di Mayhew Labs (http://bit.ly/mayhew-mux)
La Mux Shield II (Figura 8-24) è una shield attiva che supporta fino a 48 input o output utilizzando tre chip multiplexer CD74HC4067 di Texas Instruments e tre circuiti di output con registri a scorrimento. La scheda utilizza quattro dei pin digitali di Arduino per controllare i chip MUX e i registri a scorrimento. I pin digitali predefiniti sono il 2, il 4, il 6 e il 7. I pin A0, A1 e A2 di Arduino si utilizzano come input dei chip MUX. L’array di piazzole 3 × 16 (Figura 8-25) può essere utilizzato con pin header o pin socket. Ciascun canale è bidirezionale, nel senso che trasporta segnali a un output comune oppure da un input comune. Ciascun chip MUX è simile a un array di interruttori, ciascuno con una leggera resistenza mentre è chiuso e un’impedenza molto alta quando è aperto.
Figura 8-24 - La shield multiplexer attiva di Mayhew Labs (Mux II).
Figura 8-25 - I pin della shield multiplexer di Mayhew Labs.
La Mux Shield di Mayhew Labs (http://mayhewlabs.com/arduino-mux-shield) Simile alla shield descritta prima, questa shield multiplexer attiva mette a disposizione 48 linee I/O programmabili utilizzando tre chip MUX TI CD75HC4067 (vedere Figura 8-26). Inoltre, offre due grossi blocchi di pin socket header per accedere ai segnali. I pin digitali di Arduino dal 2 al 5 si utilizzano per comunicare con i chip MUX e i pin A0, A1 e A2 sono gli input analogici provenienti dai chip MUX. Si tratta di una shield che può essere montata con altre.
Figura 8-26 - La shield multiplexer attiva di Mayhew Labs (Mux).
Memoria Senza dubbio, i formati di memoria flash SD e microSD rappresentano il modo più diffuso di aggiungere della memoria per i file ad Arduino. Alla memoria flash esterna si accede per mezzo dell’interfaccia SPI e spesso, come funzionalità aggiuntiva sulle shield che utilizzano SPI come funzione principale (Ethernet, WiFi, host USB, ecc.), si trova una presa SD o microSD. La memoria flash rimovibile è un modo comodo di registrare i dati provenienti da un Arduino indipendente e poi successivamente caricarli nel proprio PC e farci quello che si desidera. Queste descrizioni non sono accompagnate da diagrammi, principalmente perché l’interfaccia SD o microSD di Arduino è semplicemente un’interfaccia SPI. Una shield ha il segnale select su un pin non comune. Questo può creare un conflitto con il software esistente. La shield con scheda SD di Seeed Studio (http://bit.ly/seeedstudio-sd-card) Progettata per schede SD di memoria flash a dimensione normale, questa shield (mostrata nella Figura 8-27) può essere facilmente utilizzata con schede microSD con un adattatore. Per l’interfaccia SPI si utilizzano i pin digitali di Arduino D4, D11,
D12 e D13. La shield, inoltre, collega i pin ICSP, I2C e UART ai connettori della PCB. Si tratta di una shield che può essere montata con altre.
Figura 8-27 - La shield con scheda di memoria SD di Seeed Studio.
La shield con scheda SD SHD-SD (http://bit.ly/shd-sd-sdcard) Questa shield SD, illustrata nella Figura 8-28, presenta una piccola area di prototipazione per aggiungere circuiti personalizzati. Può accettare schede microSD con un adattatore.
Figura 8-28 - La shield con scheda di memoria Short.
La shield utilizza i pin D10, D11, D12 e D13 di Arduino per l’interfaccia SPI con la memoria SD. Inoltre, utilizza i 3,3 V di DC di Arduino. Questa shield è più corta di quelle convenzionali, con la sistemazione dei pin come un Arduino di base. Può essere montata con altre. La shield microSD di SparkFun (http://bit.ly/sparkfun-microsd) La shield microSD di SparkFun (Figura 8-29) accetta soltanto schede microSD. Include un’area di prototipazione grande 12 per 13. Questa non ha pin socket o pin header installati, ma li si può ordinare separatamente. Utilizza i pin D10, D11, D12 e D14 di Arduino.
Figura 8-29 - La shield microSD di SparkFun.
Comunicazione Anche se una scheda Arduino può essere dotata di un’interfaccia USB (come gran parte di esse) con la possibilità di comportarsi come una porta seriale dal punto di vista del sistema host, o di un jack Ethernet come quello che si trova sulle schede Arduino Ethernet, un Arduino di base come un Uno o un Leonardo in realtà non è molto ben equipaggiato per quanto riguarda le interfacce di comunicazione di dati plug-and-play. È possibile collegare chip di adattamento dei livelli e utilizzare l’UART integrato oppure scrivere un cosiddetto “bit-banger” per inviare dati seriali, ma a volte è più comodo utilizzare qualcosa come un’interfaccia SPI con Arduino e lasciare che sia essa a occuparsi degli invii e delle ricezioni seriali. Per altre forme di comunicazioni di dati può essere coinvolto l’hardware esterno necessario e quindi è definitivamente più facile utilizzare una shield pronta per l’uso.
I/O seriale e MIDI Anche se perfino Ethernet può essere considerato una forma di comunicazione di dati seriali, qui I/O seriale si riferisce ai vecchi standard RS-232 e RS-485. Anche se sono vecchi, sono onnipresenti. I PC più vecchi sono dotati di connettori RS-232 (e anche alcuni dei modelli più nuovi ne hanno almeno uno) e RS-485 è comune nei sistemi di strumentazione, testing e misurazione distribuita. La shield RS232 di CuteDigi (http://bit.ly/cutedigi-rs232) La shield RS-232 (Figura 8-30) utilizza un IC MAX232 per eseguire l’adattamento dei livelli del segnale necessario per inviare e ricevere segnali compatibili con RS-232. Per configurare l’interfaccia seriale si utilizza una serie di jumper e per l’interfaccia seriale si possono utilizzare due qualsiasi dei pin digitali di Arduino da D0 a D7. Installando le prese di pin fornite, diventa una shield che è possibile montare con altre.
Figura 8-30 - La shield RS232 di CuteDigi.
La shield RS-485 di CuteDigi (http://bit.ly/cutedigi-rs485) La shield RS485 di CuteDigi (Figura 8-31) utilizza un chip MAX481CSA per fornire l’interfaccia elettrica RS485 utilizzando le porte Rx e Tx di Arduino (D2 e D3, rispettivamente). Sulla PCB della shield è fornita una posizione di montaggio per un connettore DB-9 opzionale. Si tratta di una shield che può essere montata con altre.
Figura 8-31 - La shield RS-485 di CuteDigi.
La shield MIDI di SparkFun (http://bit.ly/sparkfun-midi) Il MIDI è un venerabile protocollo seriale che esiste da oltre 30 anni. Tra le altre cose, lo si utilizza per controllare sintetizzatori musicali, sequencer, drum machine e mixer. Per inviare e ricevere messaggi relativi a eventi MIDI, la shield MIDI di SparkFun (Figura 8-32) utilizza i pin USART di Arduino.
Figura 8-32 - La shield MIDI di SparkFun.
Per l’I/O seriale MIDI, la shield MIDI utilizza i pin D0 e D1 (Rx e Tx, rispettivamente). È anche dotata di pulsanti su D2, D3 e D4; di LED collegati a D6 e D7; e di potenziometri collegati a A0 e A1.
Ethernet Le shield Ethernet sono molto diffuse e l’IDE di Arduino è già dotata di una suite di librerie Ethernet abbastanza completa (maggiori dettagli nel Capitolo 7). Fate attenzione che la comunicazione tra la MCU AVR della scheda Arduino e il controller Ethernet della shield utilizza l’interfaccia SPI. L’AVR non è dotato di funzione DMA (direct memory access), né in ogni caso di una memoria esterna per accedere direttamente. Con le shield Ethernet che utilizzano SPI come interfaccia con Arduino, esiste un limite ereditato sulla velocità alla quale possono spostarsi i dati tra la MCU AVR e il chip I/O Ethernet e di conseguenza sulla velocità alla quale possono spostarsi i dati sul collegamento Ethernet. Semplicemente non è possibile ottenere velocità di dati pari a 100 Mb/s (100Base-T) con un processore che va 20 MHz utilizzando un’interfaccia SPI e 10 Mb/s (10BASE-T) è un obiettivo improbabile. L’aspettativa più realistica è di 5 Mb/s. I dati vengono comunque inviati attraverso un livello fisico (l’Ethernet vero e proprio) a 10 Mb/s, soltanto a passo di byte anziché come un flusso continuo. Tutto dipende da quanto velocemente il software dell’AVR può assemblare i data in uscita e inviarli al chip Ethernet. Quindi, anche se è possibile creare un server web che stia in una scatola piccola come quelle delle mentine, non può andare molto veloce e non può gestire moltissime connessioni contemporaneamente. Quello per cui realmente si distingue l’interfaccia Ethernet è quando viene utilizzata come nodo finale di un sistema di controllo remoto o di sensori. Potete collegarla a Internet, implementare una protezione per mezzo di password e utilizzarla per ricavare dati da una posizione remota. Può essere utilizzata per rimandare dati a un controller centrale in un sistema industriale, oppure per rilevare temperatura, umidità e altri parametri per un sistema di controllo HVAC (heating, ventilation and air conditioning) come quello descritto nel Capitolo 12. La shield Ethernet con lettore di schede microSD di Vetco (http://bit.ly/vetco-ethernet) Questa shield Ethernet di Vetco (Figura 8-33) include anche un lettore di schede microSD e un pulsante di reset. I pin digitali di Arduino D10, D11, D12 e D13 si utilizzano per l’interfaccia SPI utilizzata dal chip Ethernet WIZnet W5100 e per la presa della scheda microSD. Si tratta di una shield che può essere montata con altre.
Figura 8-33 - La shield Ethernet di Vetco.
La shield Ethernet R3 con connettore microSD di Arduino (http://bit.ly/ethernet-r3) La shield Ethernet ufficiale di Arduino include un lettore di schede microSD, un pulsante di reset e tutti i componenti elettronici necessari per implementare l’interfaccia Ethernet (vedere Figura 8-34). Utilizza i pin digitali D10, D11, D12 e D13 dell’interfaccia SPI. Si tratta di una shield che può essere montata con altre.
Figura 8-34 - La shield Ethernet di Arduino.
Bluetooth Bluetooth è una tecnologia di comunicazione wireless a basso consumo e a corto raggio originariamente pensata per sostituire i cavi che scorrevano tra un computer e dispositivi come stampanti, tastiere, mouse e così via. Anche se la si utilizza ancora per queste applicazioni, ha trovato uso in molti altri tipi di applicazioni basate sulla comunicazione. Esistono diverse shield Bluetooth. La shield Bluetooth (http://bit.ly/dx-bluetooth) Questa shield è già assemblata con un modulo Bluetooth già montato sulla PCB. Notate che si tratta di una shield che può essere montata con altre e che è più corta delle tipiche shield. L’antenna è il motivo dorato che emerge dall’estremità del modulo Bluetooth (vedere Figura 8-35). Utilizza i pin Rx e Tx (D2 e D3, rispettivamente).
Figura 8-35 - La shield Bluetooth di DealeXtreme.
La shield Bluetooth di Seeed Studio (http://bit.ly/seeed-bluetooth) Questa shield Bluetooth, compatta e che può essere montata con altre (Figura 836), utilizza i pin Rx e Tx di Arduino. Inoltre collega i pin dei segnali analogici e digitali all’interfaccia con i moduli sensore.
Figura 8-36 - La shield Bluetooth compatta di Seeed Studio.
Il kit della shield wireless Bluetooth con modulo BT di ITEAD (http://bit.ly/iteadbluetooth) Questa shield (Figura 8-37) utilizza un modulo Bluetooth standard e include un’area di prototipazione sulla PCB. È una shield “corta”, nel senso che non occupa l’intera lunghezza di una scheda Arduino. Può essere montata con altre.
Figura 8-37 - La shield Bluetooth con area di prototipazione di ITEAD.
La shield d’espansione Gravity:IO di DFRobot (http://bit.ly/dfrobot-gravityio) Questa scheda multifunzione di DFRobot (Figura 8-38) combina funzionalità d’estensione I/O con una serie di prese di pin per moduli wireless Bluetooth o ZigBee. Non può essere montata con altre.
Figura 8-38 - La shield multifunzione con Bluetooth di DFRobot.
USB Una cosa che un Arduino da 8 bit non può fare è fungere da host USB per altri dispositivi USB. Una host shield USB permette di collegare ad Arduino dispositivi USB come tastiere, stampanti, alcuni strumenti di test e vari giocattoli. La host shield USB di ITEAD (http://bit.ly/itead-usb) Si tratta di una shield che può essere montata con altre con funzionalità di host USB. Inoltre fornisce i pin per i segnali digitali e analogici di Arduino e due posizioni da 10 pin sulla PCB per connettori o header di pin (vedere Figura 8-39). Si basa su un chip MAX3421E con un’interfaccia SPI con Arduino.
Figura 8-39 - La host shield USB con connessioni I/O.
La host shield USB di Circuits@Home (http://bit.ly/circuitsathome-usb) Questa shield (Figura 8-40) supporta la funzionalità USB 2.0 a piena velocità e utilizza un’interfaccia SPI con un Arduino. I segnali digitali e analogici provenienti da Arduino sono disponibili sulla PCB della shield e, con i corretti pin socket, può essere montata con altre. Utilizza un chip MAX3421E con un’interfaccia SPI con Arduino utilizzando i pin D10, D11, D12 e D13. Non include già pin socket o pin header.
Figura 8-40 - La host shield USB di Circuits@Home.
La host shield USB di Arduino (http://bit.ly/arduino-usb) Come altre host shield USB, questa scheda utilizza il chip MAX3421E con un’interfaccia SPI con Arduino utilizzando i pin D10, D11, D12 e D13. Connettori da tre e quattro pin collegano le porte di input e di output che funzionano direttamente con moduli TinkerKit (i moduli TinkerKit sono descritti nel Capitolo 9). Si tratta di una shield che può essere montata con altre (vedere Figura 8-41).
Figura 8-41 - La host shield USB di Arduino USB con connettori I/O.
ZigBee ZigBee è un noto protocollo wireless a basso consumo. Molte delle shield ZigBee per
Arduino esistenti utilizzano moduli XBee già pronti, ma la maggior parte delle schede possono accogliere qualsiasi modulo RF con il pinout corretto. Alcune sono disponibili con un modulo XBee e altre senza. Un modulo XBee da 1 mW costa circa 25 $. La shield wireless SD di Arduino (http://bit.ly/arduino-wireless) Su questa shield ZigBee (Figura 8-42), sono fornite due prese di pin per un modulo Digi XBee o qualsiasi altro modulo con una disposizione di pin compatibile. Questa shield utilizza il pin D4 di Arduino come select e i pin D11, D12 e D13 per la comunicazione SPI. Inoltre, il lettore microSD della shield utilizza l’interfaccia SPI.
Figura 8-42 - La shield ZigBee di Arduino.
La shield XBee di SainSmart (http://bit.ly/sainsm-xbee) Questa shield non include un modulo XBee, ma il layout dei pin accetta un modulo XBee standard, oppure qualsiasi altro modulo con una disposizione di pin compatibile. Notate che non c’è il lettore di microSD. Si tratta di una shield che può essere montata con altre con un offset (notate le posizioni degli header dei pin e delle prese dei pin nella Figura 8-43).
Figura 8-43 - La shield ZigBee compatta di SainSmart.
La shield XBee di Seeed Studio (http://bit.ly/seeedst-xbee) La shield XBee di Seeed Studio (Figura 8-44) presenta la posizione di montaggio che ci si aspetta in un normale modulo XBee e fornisce anche un’area di prototipazione. Questa shield utilizza i pin Rx e Tx di Arduino e anche un blocco di pin per i jumper per portare i segnali Rx e Tx provenienti da Arduino al modulo wireless.
Figura 8-44 - La shield ZigBee di SainSmart con area di prototipazione.
CAN
Controller Area Network (CAN, noto anche come CAN bus), è un segnale differenziale parente dell’RS-485 che si trova sui veicoli, nelle macchine industriali e in alcuni equipaggiamenti militari. È relativamente veloce (fino a 1 Mb/s), incorpora il rilevamento della collisione dei segnali e degli errori e supporta nodi multipli. Si utilizza con l’autodiagnosi OBD-II integrata nei modelli più recenti di automobili, veicoli elettrici e con i sensori distribuiti nelle strumentazioni scientifiche ed è integrato in alcune biciclette molto sofisticate. La shield CAN-BUS di Seeed Studio (http://bit.ly/seeed-canbus) La shield di interfaccia CAN di Seeed Studio (Figura 8-45) utilizza un bus controller CAN MCP2515 con un’interfaccia SPI e un chip ricetrasmettitore CAN MCP2551. Per i segnali del bus CAN, sono forniti sia un blocco di terminali che un connettore DB-9. Inoltre, la shield collega le comunicazioni I2C e UART provenienti da Arduino. Il layout dei pin è mostrato nella Figura 8-46.
Figura 8-45 - La shield CAN di Seeed Studio con connettori I/O ausiliari.
Figura 8-46 - Il layout dei pin della shield CAN di Seeed Studio con connettori I/O ausiliari.
La shield CAN-BUS di SparkFun (http://bit.ly/sparkfun-canbus) Questa shield CAN di SparkFun (Figura 8-47) incorpora molte delle funzionalità che si possono voler utilizzare quando si crea un dispositivo di lettura OBD-II e di cattura dei dati. È dotata di un connettore DB-9 per i segnali del bus CAN e anche di un header da 4 pin che fornisce i segnali. Sono forniti punti di connessione per un display LCD esterno e un modulo GPS EM406.
Figura 8-47 - La shield CAN di SparkFun con lettore microSD e joystick digitale.
Una funzionalità interessante è un joystick binario da quattro posizioni e incorpora un lettore di schede flash microSD. Il joystick è collegato agli input analogici di Arduino. Il chip CAN e la flash SD sono selezionati separatamente per mezzo dei pin digitali D9 e D10. I pin D3, D4, D5 e A0 non sono utilizzati dalla shield. Il layout dei pin è mostrato nella Figura 8-48.
Figura 8-48 - Il layout dei pin I/O della shield CAN di SparkFun.
La shield CAN-BUS di LinkSprite (http://bit.ly/linksprite-can-bus) Fisicamente, la shield CAN di LinkSprite (Figura 8-49) è simile alla shield di Seeed. È dotata sia di un connettore DB-9 che di un blocco di terminali da due posizioni per i segnali CAN. I pin D10, D11, D12 e D13 si utilizzano per l’interfaccia SPI con un chip CAN MCP2515.
Figura 8-49 - La shield CAN di LinkSprite.
Prototipazione Se desiderate creare una scheda personalizzata, potete costruirne un prototipo (o addirittura una shield definitiva) utilizzando una scheda shield di prototipazione. Non si tratta dello stesso processo di creazione di una shield descritto nel Capitolo 10, che coinvolge la progettazione di una PCB per una (possibile) produzione di massa. La Figura 8-50 mostra una shield di prototipazione simile a quelle descritte in questo paragrafo, con montati un sensore di temperatura e un relè. Un potenziometro è collegato ai pin +5 V, messa a terra e A0 (ingresso analogico 0) passati dalla scheda Arduino sottostante. Il potenziometro controlla il punto di temperatura impostata.
Figura 8-50 - La shield di prototipazione con il sensore/controllo della temperatura.
Questo prototipo è stato utilizzato per controllare una vecchia (e molto pericolosa) stufa elettrica portatile, che utilizzava un termostato bimetallico e che sembrava non riuscire a mantenere una temperatura superiore a +/– 15 gradi. Dal momento che il relè nominalmente sostiene soltanto 10 ampere a 120 VAC e gli elementi della stufa 15 ampere, veniva utilizzato insieme a un trasformatore da 24 VAC per controllare un contattore da 20 ampere. Funzionava abbastanza bene e manteneva il mio ufficio relativamente caldo durante l’inverno. Ma, per sicurezza, ho deciso di aggiungervi un sensore di inclinazione, un sensore di temperatura in uscita e un rilevatore del movimento della ventola. Le shield descritte in questo paragrafo non fanno altro che rappresentare quello che avete a vostra disposizione e nessuna è particolarmente complicata. Quello per cui vengono utilizzati i pin di Arduino è completamente nelle vostre mani (d’altra parte, si tratta di un prototipo) e quindi non c’è molto bisogno di diagrammi. La proto shield stackable R3 di Adafruit (http://bit.ly/stackable-r3) Questa shield (Figura 8-51) è venduta nella forma di un kit, che significa una PCB
essenziale e un sacchetto di componenti. Non è difficile da assemblare, ma è necessario saper saldare un po’.
Figura 8-51 - Il kit della shield di prototipazione stackable di Adafruit.
La proto shield Mega di Adafruit (http://bit.ly/ada-mega-proto) Questa shield di prototipazione che si può montare con altre, che è un altro kit di Adafruit, include tutti i componenti che potete vedere nella Figura 8-52. Notate la doppia riga di piazzole di saldatura per le connessioni lungo i lati della PCB. Questa permette di saldare nelle prese dei pin da terminali corti per ottenere un accesso facile ai segnali con un Arduino di tipo Mega sottostante.
Figura 8-52 - Il kit della shield di prototipazione Mega di Adafruit.
La proto shield assemblata per Arduino di CuteDigi (http://bit.ly/cutedigi-assembled) Questa shield di prototipazione (Figura 8-53) viene venduta già assemblata. Sulla PCB è inoltre dotata di prese di pin per accedere ai segnali di Arduino. Non è una shield che può essere montata con altre.
Figura 8-53 - La shield di prototipazione di CuteDigi.
La proto shield assemblata per Arduino MEGA di CuteDigi (http://bit.ly/assembledmega) Progettata per lavorare con un Arduino di tipo Mega, questa shield (Figura 8-54) presenta anche una posizione di montaggio SOIC (small-outline) per un IC. Non è una shield che può essere montata con altre.
Figura 8-54 - La shield di prototipazione Mega di CuteDigi.
La proto shield per Arduino con mini breadboard di CuteDigi (http://bit.ly/proto-bboard) Questa shield, illustrata nella Figura 8-55, include una piccola breadboard che non richiede saldature per permettervi di creare circuiti personalizzati.
Figura 8-55 - La shield di prototipazione con una breadboard di CuteDigi.
Creare una shield di prototipazione personalizzata Potete montare una shield che funzioni utilizzando nient’altro che una PCB di prototipazione e alcuni pin e connettori. La dimensione della PCB non è realmente importante, purché i pin si allineino con le prese della scheda Arduino. Il kit della shield DIT di Adafruit Se esistesse un premio per il kit della shield più semplice, sicuramente questo starebbe tra i primi a contenderselo. Questa shield, formata da una PCB di prototipazione e quattro connettori di pin dai terminali lunghi (Figura 8-56), vi permette di montarvi tutto quello che desiderate. Si rivela utile per prototipare un nuovo progetto di shield, oppure soltanto per mettere rapidamente diverse cose insieme ed è ideale per utilizzare un modulo esistente di qualche tipo che non era mai stato pensato per collegarsi con Arduino.
Figura 8-56 - Il kit della shield DIY di Adafruit.
Purtroppo il prodotto è stato abbandonato da Adafruit, ma non vi serve altro che una PCB di prototipazione (che si trovano facilmente presso vari rivenditori) e le prese dei pin, che distribuiscono Adafruit e altri rivenditori. Dal momento che le piazzole dei pin sulla scheda Arduino utilizzano la distanza standard di 0,1 pollici (2,54 mm), è facile creare qualcosa con componenti di prototipazione di base che possono fungere da shield.
Controllo del movimento Il controllo del movimento è un argomento di grande interesse nel mondo di Arduino. Da robot mobili programmabili a incisori CNC, da stampanti 3D a scanner laser e perfino controlli automatici per seguire il sole per i pannelli solari e sculture cinetiche, Arduino è stato utilizzato per controllare motori DC, servomotori e motori passo-passo fin dall’inizio. Come potete immaginare, per ciascun tipo di motore esistono diverse shield e questo non è che un piccolo campionario di tutto quello che avete a disposizione.
Controllo di motori DC e passo-passo Le shield per controllare i motori che si basano su un ponte H (un tipo di interruttore che porta tensione allo stato solido) di solito possono essere utilizzate per controllare motori DC del tipo a spazzole oppure motori passo-passo. Fondamentalmente, le shield di questo tipo possono essere utilizzate per controllare qualsiasi carico DC induttivo, compresi solenoidi e relè. La shield Rugged Motor Driver (http://bit.ly/rugged_motor) La shield Rugged Motor Driver di Rugged Circuits (Figura 8-57) può gestire due motori DC del tipo a spazzole oppure un motore passo-passo bipolare. È valutato per un massimo di 30 V a corrente di picco 2,8 A. La shield utilizza i pin D3, D11, D12 e D13 per gli input enable (di attivazione) e di controllo della direzione. Gli input
enable possono essere gestiti con un segnale PWM per controllare in modo fluido un motore DC. Sul sito web trovate maggiori dettagli sulla gestione della tensione e il software.
Figura 8-57 - La shield Rugged Motor Driver.
La shield per gestire motori di SainSmart (http://bit.ly/sainsm-motor) La shield per gestire motori di SainSmart (Figura 8-58) si basa su un driver IC L293D da quattro canali. Può gestire quattro motori DC del tipo a spazzole oppure due motori passo-passo a un massimo di 10 V. È dotato di terminali per una fonte di alimentazione esterna. Sul sito web trovate maggiori dettagli sulla gestione della tensione e il software.
Figura 8-58 - La shield di gestione dei motori L239D di SainSmart.
La shield per gestire motori di Arduino (http://bit.ly/arduino-motor) La shield per gestire motori di Arduino.cc (Figura 8-59) si basa sul dual-driver IC L298. La si può utilizzare con relè, solenoidi, motori DC e motori passo-passo. Una funzionalità interessante è la sua capacità di misurare il consumo di corrente, che può rivelarsi utile per rilevare un motore in stallo. Notate, inoltre, che è dotato di connettori modulari che sono compatibili con vari moduli TinkerKit (descritti nel Capitolo 9).
Figura 8-59 - La shield di gestione dei motori di Arduino.
Controllo di PWM e servomotori I piccoli servomotori utilizzati nei modellini RC e nella robotica a piccola scala funzionano posizionando un’armatura relativa a una serie di impulsi di controllo di lunghezza variabile ma a frequenza costante. La lunghezza (i momenti “attivi”) degli impulsi determina l’angolo di rotazione del servo. Una shield per PWM/servo può essere utilizzata anche per gestire un motore DC, per controllare con precisione la luminosità di uno o più LED, oppure per controllare un attuatore lineare. La shield per PWM/Servo a 16 canali e 12 bit (http://bit.ly/ada-16-pwm) Questa shield (Figura 8-60) utilizza un controller IC PWM PCA9685 a 16 canali con un’interfaccia I2C. Ha la capacità di generare un segnale PWM unico e programmabile su ciascun output e non richiede l’attenzione costante di Arduino.
Figura 8-60 - La shield per PWM/servo con interfaccia I2C di Adafruit.
La shield per PWM/Servo a 27 canali di LinkSprite (http://bit.ly/linksprite-27-pwm) Questa shield di LinkSprite (Figura 8-61) utilizza un microcontroller IC STM32F103C8T6 per generare fino a 27 output PWM unici. Vale la pena sottolineare che l’STM32F103C8T6 è un dispositivo ARM Cortex-M3 RISC a 32 bit con fino a 128 KB di memoria flash e 20 KB di SRAM. In realtà, il microcontroller di questa shield dal punto di vista delle capacità di calcolo è più potente dell’AVR dell’Arduino sulla quale è montata. Comunica con Arduino utilizzando l’interfaccia SPI.
Figura 8-61 - La shield per servo di LinkSprite.
La shield per PWM di SparkFun (http://bit.ly/sparkfun-pwm) La shield per PWM di SparkFun (Figura 8-62) utilizza un TLC5940 IC ed è in grado di produrre 16 output PWM. Il TLC5940 è in grado di gestire LED oppure servo motori. Utilizza un’interfaccia seriale clocked di tipo SPI, ma riceve soltanto dati. Trovate maggiori informazioni e librerie software presso SparkFun.
Figura 8-62 - La shield per PWM di SparkFun.
Display Le shield con display per le schede Arduino possono contenere LED (light-emitting diode), array di LED, un LCD (liquid-crystal display), oppure un display grafico a colori. Alcune di queste shield utilizzano diversi output digitali di Arduino, mentre altre utilizzano interfacce SPI o TWI (I2C). Qualunque cosa vogliate visualizzare, è probabile che esista una shield con display che faccia al caso vostro.
Gli array di LED In sé, un solo array di LED fa ridere, ma quando li si mette uno a fianco all’altro è possibile creare display rettangolari di vari colori. Per ulteriori informazioni sulle shield elencate qui, potete consultare il sito web di ciascuna di esse: •
La shield LoL di Adafruit, http://bit.ly/ada-lol (Figura 8-63)
Figura 8-63 - La shield con un array di 9 × 14 LED di Adafruit.
•
La shield SMD LoL di Solarbotics, http://bit.ly/solarbio-smd-lol (Figura 8-64)
Figura 8-64 - La shield con un array di 9 × 14 LED di Solarbotics.
•
La shield NeoPixel di Adafruit, http://bit.ly/ada-neo (Figura 8-65)
Figura 8-65 - La matrice di pixel con 40 LED RGB di Adafruit.
I display di LED a sette segmenti I display di LED a 7 segmenti esistono praticamente da quando esistono i LED. Anche se attualmente sono considerati abbastanza obsoleti, i display a 7 segmenti hanno ancora delle carte da giocare, quando si ha bisogno di cifre grandi e luminose che si possano vedere facilmente dall’altra parte di una stanza. Vi consiglio di guardare anche la shield multifunzione elencata in “Shield varie” a pagina 273, dotata di display numerico di LED a 4 cifre. •
La shield di cifre 4 x 7 segmenti compatibile con Arduino, http://bit.ly/arduino-7seg (Figura 8-66)
Figura 8-66 - La shield con display a 7 segmenti di Nootropic Design.
I display LCD Molte shield LCD basate sui caratteri e a basso costo utilizzano display 16 × 2 (16 caratteri in 2 righe) con lettere bianche su schermo blu, lettere rosse su schermo nero, oppure lettere nere su schermo verde. Esistono anche altre combinazioni, come configurazioni 16 × 4 e 20 × 4. La maggior parte di questi tipi di shield si basano sul controller LCD HD44780 di Hitachi o su qualcosa di simile. Esistono anche display LCD che possono indirizzare pixel e mostrare bitmap. Alcuni di questi, come il noto Nokia 5110, sono disponibili presso vari rivenditori e sono facili da interfacciare con Arduino. Potete anche trovare display con risoluzioni di 128 × 64 e 160 × 128 pixel senza dover cercare troppo, ma non molti di questi sono disponibili nella forma di una shield compatibile con Arduino. Nel Capitolo 9 trovate ulteriori informazioni sui componenti display che non sono shield. La shield con keypad LCD di SainSmart (http://bit.ly/sainsmart-keypad) Si tratta di un design di shield LCD comune, mostrato nella Figura 8-67, che utilizza un modulo display LCD 16 × 2 e il controller LCD HD44780 di Hitachi (il modulo display è disponibile separatamente e uno è utilizzato nel generatore di segnale descritto nel Capitolo 11 e nel termostato descritto nel Capitolo 12).
Figura 8-67 - La shield con keypad LCD 16 × 2 di SainSmart.
Questa shield LCD utilizza un driver del voltaggio per i cinque interruttori a pulsante, in modo che la pressione di ciascun pulsante produca una tensione diversa. La Figura 8-68 mostra come funziona. Il vantaggio offerto da questo approccio è che gli input dei cinque interruttori sono condotti attraverso un input analogico.
Figura 8-68 - Lo schema della shield LCD di SainSmart.
La shield con keypad LCD di DFRobot (http://bit.ly/dfrobot-keypad) Questa è simile alla shield LCD di SainSmart, a eccezione che per le connessioni dei pin analogici con l’Arduino sottostante (vedere Figura 8-69). Secondo la documentazione del rivenditore, i pin addizionali sono pensati soprattutto per interfacciarsi con un modulo radio APC220 oppure con un modulo Bluetooth.
Figura 8-69 - La shield con keypad LCD 16 × 2 con pin analogici di DFRobot.
Il kit della shield LCD di Adafruit (http://bit.ly/adafruit-lcd) Per controllare il display LCD, il kit della shield LCD 16 × 2 di Adafruit, mostrato nella Figura 8-70, utilizza l’interfaccia I2C e un expander IC I/O MCP232017 (utilizzato anche nel Capitolo 10). Questo fa sì che la shield utilizzi soltanto due dei pin di Arduino, A4 e A5, per l’interfaccia I2C. L’LCD e i pulsanti sono tutti collegati all’IC MCP23017 e non utilizzano un partitore resistivo. Notate che si tratta di un kit, ma che non è troppo difficile da assemblare.
Figura 8-70 - Il kit della shield LCD con display di 16 × 2 caratteri di Adafruit.
Il modulo Nokia LCD5110 con SD (http://bit.ly/nokia_lcd) Questa shield, illustrata nella Figura 8-71, combina un display LCD Nokia 5110 con un lettore di schede flash SD. Utilizza i pin D3, D4, D5, D5 e D7 per il display e i pin D10, D11, D12 e D13 per la scheda SD. I pin D0, D1 e D2 restano disponibili per altre applicazioni.
Figura 8-71 - La shield LCD Nokia 5110 di Elechouse.
A differenza dei display basati su 16 × 2 caratteri, il 5110 è un LCD che supporta immagini grafiche con un’area di visualizzazione di 48 × 84. Originariamente è stato creato per i telefoni cellulari e adesso tutte le unità che si trovano sono avanzi di
produzione. Alcuni possono presentare graffi o altri leggeri difetti. Dovete tenere presente anche che, quando scompariranno, finirà la loro storia. Quindi, non è una buona idea progettare un nuovo prodotto utilizzandoli, ma sono divertenti per giocarci e sono relativamente economici.
I display TFT I TFT LCD (thin-film transistor liquid crystal display), detti più brevemente soltanto TFT, sono un tipo di display comune che si trova nei monitor dei computer, nei display dei registratori di cassa, nei telefoni cellulari, nei tablet e praticamente in tutto quello che presenta un display grafico a colori. Una shield con TFT a colori per Arduino può mostrare migliaia di colori a risoluzioni come 240 × 320 pixel. Si trovano display più grandi, ma generalmente questi non ci stanno in una shield. Le shield TFT di solito sono economiche: la maggior parte di loro utilizzano un’interfaccia SPI e alcune sono dotate di un’interfaccia digitale parallela per la generazione di immagini ad alta velocità. La touch shield TFT LCD da 2,4” di ITEAD (http://bit.ly/ITEAD-tft) Questa shield, illustrata nella Figura 8-72, utilizza un’interfaccia digitale parallela con Arduino. Sulla shield, è utilizzata un’interfaccia a 8 bit è con un TFT controller S6D1121 e le funzioni touchscreen sono gestite dal chip TSC2046. Per informazioni più dettagliate, potete consultare il sito web del rivenditore.
Figura 8-72 - La shield TFT a colori da 2,4 pollici con touchscreen di ITEAD.
La touch shield TFT da 28” di Adafruit (http://bit.ly/ada-tft) La shield TFT da 2,8 pollici di Adafruit (Figura 8-73) utilizza un’interfaccia SPI ad alta velocità per il controller di display ILI9341 con un buffer di RAM video integrato e il controller del touchscreen STMPE610. Incorpora anche un lettore di scheda flash microSD. La shield utilizza i pin digitali di Arduino dal D8 al D13, il controller del
touchscreen utilizza il pin D8 e select del lettore microSD si trova sul pin D4.
Figura 8-73 - La shield TFT da 2,8 pollici di Adafruit con touchscreen resistivo.
Shield per la strumentazione Anche se non ne esistono tante come nel caso di altri tipi di shield, si trovano shield per la strumentazione. Queste includono shield per la registrazione dei dati, analizzatori logici e convertitori analogo-digitale (A/D) di precisione. Strumentazione, in questo caso, si riferisce alla possibilità di percepire e catturare dati dal mondo fisico, oppure di generare un segnale analogico. Non esistono molte shield con funzionalità integrate di cattura e conversione dei dati, principalmente per via del fatto che la MCU AVR che si trova su Arduino ha già gran parte di queste funzioni nel chip. Il convertitore A/D (ADC) integrato delle MCU AVR utilizzate con le schede Arduino ha una risoluzione di 10 bit, che dà una risoluzione di conversione di 1/1.024 per DN, o numero digitale. Se avete bisogno di una risoluzione migliore (12, 16 o addirittura 24 bit, per esempio), dovete prendere in considerazione qualche tipo di modulo o shield aggiuntivi. La shield per la registrazione dei dati di Adafruit (http://bit.ly/1Tjlu5V) La shield per la registrazione dei dati di Adafruit, mostrata nella Figura 8-74, include un lettore di scheda flash SD e un chip real-time clock (RTC). L’RTC può essere alimentato da una batteria, quando l’alimentazione principale che proviene
dall’Arduino di base è spenta. Per i circuiti personalizzati si utilizza una piccola griglia di prototipazione. Non è una shield che può essere montata con altre.
Figura 8-74 - La shield per la registrazione dei dati di Adafruit assemblata.
La shield Ultimate GPS Logger di Adafruit (http://bit.ly/ada-gps) Questa shield, mostrata nella Figura 8-75, incorpora un ricevitore GPS, oltre a un lettore di flash SD e a un chip RTC. L’output del GPS può essere registrato automaticamente nella scheda di memoria flash. Non è una shield che può essere montata con altre.
Figura 8-75 - La shield per la registrazione dei dati GPS di Adafruit.
La shield analizzatore (http://www.arduinolab.us)
logico
e
generatore
di
segnale
di
HobbyLab
In realtà, si tratta di un analizzatore logico indipendente su una shield. Controlla i segnali di Arduino senza interferire con essi, cosa che si rivela utile per vedere che cosa sta succedendo sui pin I/O. Oltre alla funzionalità dell’analizzatore logico, include anche un decodificatore SPI, un decodificatore UART e un monitor da un filo. Non comunica direttamente con Arduino, ma utilizza un’interfaccia USB per interagire con un computer host. Si tratta di una shield che può essere montata con altre (vedere Figura 8-76).
Figura 8-76 - L’analizzatore logico e generatore di segnale di HobbyLab.
La shield ADC da 16 canali e 24 bit di Iowa Scaled Engineering (http://bit.ly/ardltc2499) Questa shield incorpora un convertitore A/D da 24 bit e un riferimento di precisione della tensione per ottenere le letture di diversi input differenziali o single-ended. È dotata anche di una EEPROM integrata per salvare e leggere dati di calibrazione e configurazione. Comunica con Arduino per mezzo dell’interfaccia I2C (TWI). Si tratta di una shield che può essere montata con altre (vedere Figura 8-77).
Figura 8-77 - La shield di acquisizione dei dati ADC da 24 bit di Iowa Scaled Engineering.
La shield Power DAC di Visgence (http://bit.ly/power-dac)
Una funzione che manca alla MCU AVR e per estensione ad Arduino è un convertitore digitale-analogico (DAC) integrato. L’ADC interno dell’AVR incorpora un DAC da 10 bit, ma l’output non è disponibile esternamente. Anche se le shield per l’output audio sono facili da trovare, non sembra che ne esistano molte di puro output DC DAC. La shield Power DAC di Visgence (Figura 8-78) fornisce tre canali di output analogico con la possibilità di generare fino a 250 mA di tensione.
Figura 8-78 - La shield DAC da 12 bit di Visgence.
Shield adattatori Una shield adattatore si utilizza come interfaccia fisica tra quelli che altrimenti sarebbero due moduli fisicamente incompatibili. La differenza principale tra una shield adattatore e una shield che trasporta il segnale (vedere “Shield che trasportano il segnale” a pagina 236), almeno per quando riguarda come sono organizzate le shield in questo capitolo, è che un adattatore è pensato per fungere da interfaccia fisica. Una shield che trasporta il segnale non si occupa delle differenze fisiche, ma soltanto dei segnali. La shield di espansione per Arduino Nano di Tronixlabs Australia (http://bit.ly/expnano) Una scheda Nano presenta tutte le funzionalità dell’Arduino di base, più grande, ma non funziona con le shield convenzionali. Questa scheda, mostrata nella Figura 8-79, risolve questo problema collegando i pin della Nano agli header dei pin e opzionalmente ai connettori standard dei pin.
Figura 8-79 - La shield adattatore per la Nano di Tronixlabs.
La scheda di espansione I/O per Arduino Nano (eBay) (http://bit.ly/exp-nano-ebay) Un altro esempio di adattatore per la scheda Nano (Figura 8-80). Questa si trova su eBay, ma ne esistono anche altre simili.
Figura 8-80 - La scheda di espansione per Arduino Nano.
La shield per terminali a vite (http://bit.ly/screw-term) Anche se tecnicamente non si tratta di una shield, di per sé questi utili adattatori permettono di collegare fili isolati fino a 18 AWG. Si trovano facilmente presso vari rivenditori. Notate che questi componenti possono essere montati l’uno sull’altro (vedere Figura 8-81).
Figura 8-81 - Gli adattatori dei terminali.
Shield varie Questo paragrafo descrive alcune shield utili che non rientrano esattamente in categorie definite. A me piace chiamarle “wing shield” perché permettono di creare collegamenti più ordinati e le shield multifunzione mostrate qui presentano una vasta gamma di utilizzi. La Proto-ScrewShield (Wingshield) di Adafruit (http://bit.ly/ada-proto-screw) La Wingshield, conosciuta anche come Proto-ScrewShield, è una shield passiva con due serie di blocchi di terminali in miniatura (vedere Figura 8-82). Se prevedete di incorporare una scheda Arduino in un prodotto commerciale o in un laboratorio, potete prendere in considerazione una shield come questa. Le viti del blocco di terminali forniscono una connessione molto più sicura e affidabile dei jumper dei pin. L’area di prototipazione al centro della shield può essere utilizzata per montare moduli sensore, oppure può contenere un circuito personalizzato. La shield include un interruttore di reset e un LED. Inoltre, può essere montata con altre. Attenzione perché si tratta di un kit e quindi si presenta come una PCB e un sacchetto di componenti. Assemblarlo non è difficile, ma è necessario saper saldare.
Figura 8-82 - La Wingshield di Adafruit.
La Screw ProtoShield di DFRobot (http://bit.ly/screw-protoshield) Come la Wingshield di Adafruit, questa shield (Figura 8-83) fornisce terminali a vite per ciascuno dei segnali provenienti da Arduino, ma è già completamente assemblata. Inoltre si tratta di una shield che può essere montata con altre e quindi può essere collocata sotto altre shield mantenendo la possibilità di accedere ai blocchi di terminali.
Figura 8-83 - La shield con blocchi di terminali di DFRobot.
La shield multifunzione DIY di DealeXtreme (http://bit.ly/diy-multi) Si tratta di una shield interessante, con un lettore di LED numerico da 4 cifre, un punto di interfaccia per un modulo Bluetooth APC220, diversi interruttori a pulsante collegati con i pin di Arduino A1, A2 e A3m, un interruttore di reset e un potenziometro collegato all’input A0 (vedere Figura 8-84). Quattro LED sono collegati ai pin digitali D10, D11, D12 e D13 e un header da 3 × 4 pin collega i pin D5, D6, D9 e A5, oltre a +5 V e messa a terra. Purtroppo, questa shield è anche piuttosto mal documentata e riuscire a trovare qualche informazione utile può richiedere un po’ di ricerche. Potete trovare ulteriori informazioni sul forum di HobbyComponents.com (http://bit.ly/dx-diy-hc). Inoltre, potete scaricare una raccolta di sketch di esempio e uno schema da http://bit.ly/dx-diy-sketch. Notate che i nomi delle directory nell’archivio ZIP sono tutti in cinese, ma la maggior parte degli sketch presentano commenti in inglese.
Figura 8-84 - La scheda d’espansione della shield multifunzione DX DIY.
L’organizzazione dei vari componenti della shield multifunzione è mostrata nella Figura 8-85. Notate che non si tratta di una shield che può essere montata con altre e la cosa ha senso, dal momento che montando un’altra shield sopra di essa si renderebbe inutile il display LED.
Figura 8-85 - Le funzionalità principali della shield multifunzione.
Lo schema fornito per questa shield è in un certo senso criptico e quindi ne ho creato una versione alternativa, mostrata nella Figura 8-86. Notate che questa shield utilizza tutti i pin di Arduino. La Tabella 8-1 elenca i pin di Arduino e mostra per che cosa li utilizza la shield multifunzione.
Figura 8-86 - Lo schema della shield multifunzione.
Tabella 8-1 - Le funzioni dei pin della shield multifunzione di Arduino.
Pin
Utilizzo
D0
Rx dal modulo wireless
D1
Tx al modulo wireless
D2
ID ricevuto
D3
Controllo dell’annunciatore
D4
Blocco del display LED
D5
A D5 su blocco I/O
D6
A D6 su blocco I/O
D7
Clock del display LED
D8
Input di dati seriali del display LED
D9
A D9 su blocco I/O
D10
LED
D11
LED
D12
LED
D13
LED
A0
Cursore del potenziometro
A1
Interruttore S3
A2
Interruttore S2
A3
Interruttore S1
A4
Input del sensore di temperatura
A5
A5 su blocco I/O
Questa shield è un buon esempio di quello che spesso si incontra con una nuova shield. La documentazione può essere ridotta al minimo e gran parte di essa può essere in una lingua che non capite (il cinese, in questo caso, ma anche l’inglese più essere difficile per alcuni utenti). Lo schema è corretto, ma può risultare difficile da capire a una prima occhiata e non c’è una descrizione dettagliata del pinout (bè, in realtà adesso sì).
Shield di Arduino non comuni Oltre alla vasta gamma di shield dalle I/O RS-232 a quelle per controllare PWM e servo, esistono anche shield create per applicazioni specifiche. Alcune stampanti 3D open source utilizzano una scheda Arduino come controller principale e le interfacce di controllo, nella forma di shield, si trovano facilmente. Alcune di queste shield sono pensate per le schede Arduino di tipo Mega e le loro dimensioni sono studiate di conseguenza. Altre shield non comuni non rientrano esattamente in nessuna delle categorie che abbiamo visto in questo capitolo, ma sono comunque interessanti. Un esempio di questo tipo di shield è la Gameduino. Si tratta essenzialmente di un contenitore per un chip FPGA (field-programmabile gate array) e può essere utilizzata per altre applicazioni, oltre che per i videogiochi. La shield Qunqi CNC per Arduino V3 Engraver (http://bit.ly/qunqi-cnc) Questa shield, illustrata nella Figura 8-87, non include moduli di gestione dei motori, ma se ne trovano facilmente. Un tipico modulo driver il utilizza driver chip microstepping A4988 DMOS di Allegro.
Figura 8-87 - La scheda d’espansione Qunqi A4988 driver CNC.
La shield SainSmart RepRap Arduino Mega Pololu (http://bit.ly/sainsmart-reprap) Il costruttore di RepRap 3D (http://reprap.org/), pubblicizzato come “la prima macchina per scopi generali dell’umanità capace di replicarsi da sola”, è un costruttore compatto che può creare componenti per altre macchine RepRap, oltre a molte altre cose. Questa shield, mostrata nella Figura 8-88, è pensata per sostituire le parti elettroniche di un dispositivo di tipo RepRap e come processore utilizza un Arduino di tipo Mega.
Figura 8-88 - La shield RAMPS 1.4 RepRap per stampanti 3D di SainSmart.
excamera Gameduino (http://bit.ly/excam-gameduino) Questa shield utilizza un Xilinx FPGA (Figura 8-89) per controllare le immagini e i suoni in una console di giochi fatta in casa. Come interfaccia con i controlli e per
dirigere i giochi si utilizza un Arduino. Gameduino è open source, per cui tutti i dettagli tecnici sono a disposizione di chiunque ed è possibile riproporre il FPGA per qualcosa di diverso dai giochi.
Figura 8-89 - La shield game controller excamera Gameduino.
Fonti La Tabella 8-2 elenca i rivenditori e i produttori menzionati in questo capitolo. Naturalmente ce ne sono molti altri non elencati qui, che sono comunque ottimi posti dove cercare shield utili o innovative. Digitando “Arduino shield” nel campo di ricerca di Google, ottenete circa 400.000 risultati e quindi, come vedete, non mancano i posti dove cercare prodotti e informazioni. Il solo fatto che un rivenditore o un produttore non sia menzionato qui non significa che non valga la pena di essere preso in considerazione. Semplicemente, cercare di includere tutti in un mercato volatile come questo, che propone tanti prodotti diversi, sarebbe come il supplizio di Sisifo. Tabella 8-2 - Elenco di rivenditori e produttori di shield.
Nome
URL
Adafruit
www.adafruit.com
Arduino
store.arduino.cc
Arduino Lab
www.arduinolab.us
Circuits@Home
www.circuitsathome.com
CuteDigi
store.cutedigi.com
DFRobot
www.dfrobot.com
DealeXtreme (DX)
www.dx.com
Elecfreaks
www.elecfreaks.com
Elechouse
www.elechouse.com
excamera
www.excamera.com
Iowa Scaled
www.iascaled.com
Engineering iMall
imall.itead.cc
Macetech
www.macetech.com/store/
Mayhew Labs
www.mayhewlabs.com
Nootropic Design
www.nootropicdesign.com
Numato
www.numato.com
RobotShop
www.robotshop.com
Rugged Circuits
www.ruggedcircuits.com
SainSmart
www.sainsmart.com
Seeed Studio
www.seeedstudio.com
SparkFun
www.sparkfun.com
Tindie
www.tindie.com
Tronixlabs
www.circuitsathome.com
Vetco
www.vetco.net
9 Moduli e componenti I/O
Anche se molte delle shield disponibili per Arduino presentano moltissime funzioni interessanti e utili già integrate, non sono onnipotenti. Né potrebbero esserlo, dal momento che esiste una vasta gamma di tipi diversi di sensori, controlli e attuatori che possono essere utilizzati con Arduino. Molti rivenditori offrono componenti sensore aggiuntivi con una sola funzionalità e piccoli moduli PCB per Arduino. Questi includono sensori di temperatura e umidità, rilevatori di vibrazioni, fotorivelatori, tastierini, joystick e perfino laser a stato solido. Quasi tutti i sensori, i controlli o gli attuatori che possono essere utilizzati con i microcontroller possono essere utilizzati anche con Arduino. Presentano alcuni limiti per quanto riguarda l’alimentazione, a seconda del tipo di microcontroller che si trova su Arduino (3,3 V o 5 V), ma per lo più si tratta di un dettaglio di minore importanza che può essere risolto con alcuni semplici componenti elettronici e un alimentatore adeguato. In questo capitolo vedremo sia moduli I/O sia singoli componenti. I moduli I/O sono piccole PCB che eseguono una funzione specifica e utilizzano soltanto alcuni componenti attivi o addirittura nessuno. Sono piccoli, circa della dimensione di un francobollo o meno, e per i collegamenti utilizzano pin. Funzionano bene con jumper femmina-maschio oppure femmina-femmina e, in alcuni casi, per collegarli a una shield creata esattamente per questo scopo si possono utilizzare cavi speciali con diversi fili. Qui vedremo i prodotti di KEYES, SainSmart e TinkerKit, principalmente perché sono ottimi rappresentanti dei moduli in generale. Altri moduli che vale la pena prendere in considerazione sono le serie di moduli e di shield Grove che si trovano presso Seeed Studio e i moduli di TinyCircuits. I singoli componenti I/O possono essere di vario tipo, da LED a display grafici, da sensori meccanici come interruttori e relè reed a sensori di temperatura e umidità indipendenti. Qui i sensori singoli sono trattati dopo i moduli intenzionalmente, perché molti dei moduli utilizzano i componenti descritti là. Tra i vari paragrafi sono forniti i riferimenti incrociati necessari. Quasi tutti apprezziamo l’ordine e l’affidabilità. Purtroppo, utilizzare gli onnipresenti ponticelli per collegare moduli e altri componenti può diventare rapidamente tutto tranne che ordinato e i connettori da crimpare che si utilizzano sulle estremità dei ponticelli tendono a rivelarsi troppo allentati per i pin dei moduli.
Anziché rassegnarsi a saldarli direttamente ai pin di un modulo, oppure a nascondere i connettori dei jumper con una goccia di silicone per tenerli fermi al loro posto, si possono utilizzare connettori modulari. Questi possono essere fatti su misura per applicazioni specifiche utilizzando strumenti manuali semplici, oppure si può decidere di utilizzare un sistema come TinkerKit, Grove o TinyCircuits. Questo capitolo offre una panoramica dei metodi per collegare moduli ad Arduino che permettono di non creare un groviglio di ponticelli.
I moduli I moduli sensore e I/O sono senza dubbio il modo più comodo di collegare un sensore, un interruttore, un relè, oppure un microfono ad Arduino e potervi fare esperimenti. La Figura 9-1 mostra diversi tipi di modulo.
Figura 9-1 - Diversi tipi e dimensioni di modulo sensore.
Alla lunga, è facile ritrovarsi con una grande quantità di moduli, alcuni dei quali più utili di altri. Vi suggerisco di cominciare con i kit di moduli più grandi che vi possiate permettere e poi scoprire quali utilizzate maggiormente. Di questi, vi conviene tenerne diversi a portata di mano, mentre quelli che utilizzate di meno potete metterli da parte per progetti futuri. ATTENZIONE Le descrizioni che trovate online di come funzionano vari moduli non sono sempre corrette. Potrebbero essere problemi di traduzione, ma a volte le descrizioni online dichiarano che quando è attivo un modulo genera un output high, quando in realtà genera un output low. Prima di collegarlo a un circuito, vi conviene sempre controllare bene come funziona un modulo con un multimetro digitale (DMM). La maggior parte dei moduli elencati in questo
paragrafo sono stati testati per determinare come funzionano davvero e le descrizioni offerte qui corrispondono a queste scoperte. Detto questo, non posso affermare che tutti i moduli che possono assomigliare a quelli elencati in questo capitolo si comportino nello stesso modo o presentino le stesse funzioni dei pin. In quest’angolo dell’universo, la standardizzazione non è ancora arrivata.
Per quanto riguarda gli schemi dei moduli elencati qui, be’, in realtà non ne esistono di ufficiali che io sia riuscito a trovare. Diverse anime coraggiose su Internet si sono prese la briga di creare le PCB di alcuni dei moduli. Ho cercato di raccogliere quelle che riuscivo a trovare e di combinarle con i miei sforzi di ingegneria inversa. In alcuni casi, il risultato è uno schema completo e in altri ho soltanto voluto verificare che i pin facessero veramente quello che diceva la documentazione disponibile (seppur minima).
I fattori di forma fisici I moduli possono presentare diverse dimensioni, da 1,8 per 1,5 cm (approssimativamente 3/4 per 9/16 pollici) a 4,2 per 1,7 cm (approssimativamente 1 11/16 per 5/8 pollici), mentre alcuni possono raggiungere i 3,4 per 2,5 cm (approssimativamente 1 5/16 per 1 pollice), nel caso di un relè modulare da 5 V. La Figura 9-2 mostra una gamma di dimensioni dei moduli. Notate che queste sono dimensioni approssimative. Le dimensioni reali delle PCB possono variare di circa +/– 1 mm (0,04 pollici), a seconda di dove sono stati prodotti i moduli.
Figura 9-2 - Esempi di dimensioni di moduli che si trovano spesso.
Sulla PCB, molti moduli presentano dei fori di montaggio sufficienti per una vite a testa tonda #2 (2,03 mm). L’equivalente metrico è di solito una dimensione pari a M1.6 o M1.8. La Figura 9-3 mostra due moduli montati uno sopra l’altro utilizzando viti a testa
tonda da 2-56 e distanziatori di nylon. Si tratta di un sensore di temperatura da un filo con un modulo interruttore a inclinazione al mercurio.
Figura 9-3 - Moduli montati utilizzati viti a testa tonda #2 e distanziatori.
Purtroppo, non tutti i moduli possono essere montati bene con altri. A volte, i fori di montaggio non presentano la stessa distanza, oppure possono trovarsi nel posto sbagliato sulla PCB e non permettere ai moduli di essere montati uno sopra l’altro. Alcuni moduli non sono dotati di fori di montaggio e quindi si deve sempre controllare prima, per assicurarsi che sarà possibile.
Le interfacce I pinout che si utilizzano con i vari moduli PCB possono variare da un tipo all’altro e quindi, a parte nel caso della serie TinkerKit, non esiste realmente uno standard. La Figura 9-4 mostra alcune delle variazioni che potete aspettarvi di trovare.
Figura 9-4 - Configurazioni tipiche del pinout utilizzate con i moduli.
NOTA Anche se potete dare per scontato che i moduli dotati di tre o quattro pin sono compatibili con shield d’estensione I/O con connettori modulari o i pin I/O organizzati in blocchi (come quelli descritti nel Capitolo 8), non sempre è così. La compatibilità dei pin sui moduli e le shield è garantita soltanto quando si collega una famiglia di moduli a una shield progettata espressamente per lavorare con quei componenti. Ne è un esempio TinkerKit, ma soltanto quando si collegano moduli TinkerKit a una shield d’estensione TinkerKit. Prima di collegare un modulo, conviene sempre controllarne i pin, per verificare le posizioni della tensione e del segnale.
Dal momento che l’AVR è un dispositivo piuttosto robusto, è possibile collegare molti sensori direttamente agli input di Arduino e anche alcuni dispositivi di output. I dispositivi di output che hanno bisogno di più alimentazione, come i laser a stato solido o i LED RGB, in realtà hanno bisogno di un driver di un qualche tipo per ottenere una tensione superiore a quella che il chip AVR di Arduino è in grado di fornire direttamente (ricordate le specifiche descritte nel Capitolo 3). Alcuni moduli di output sono dotati di un’interfaccia ad alta tensione integrata, ma altri no. Per fornire con sicurezza la corrente necessaria a un dispositivo come un modulo relè o LED laser, si può utilizzare un circuito semplice, come quello mostrato nella Figura 9-5. Il valore di R nel circuito a destra nella Figura 9-5 viene determinato dal LED e dalla quantità di corrente necessaria per il suo funzionamento. Purché la tensione non superi quella tollerata dal transistor, dovrebbe funzionare bene.
Figura 9-5 - Un circuito di output per dispositivi ad alta tensione.
Un’altra opzione è un IC per uno scopo speciale come il MAX4896, mostrato nella Figura 9-6, che utilizza un’interfaccia SPI e un Arduino può interfacciarsi direttamente all’IC. Anche se è pensato per gestire piccoli relè, questo IC è in grado di gestire LED grandi con la stessa facilità.
Figura 9-6 - Un IC di gestione dell’output per diversi relè o altri carichi.
Dove trovare i moduli La Tabella 9-1 suggerisce dove trovare moduli con una sola PCB e kit di sensori con 24, 36 o più moduli. Se ne trovano anche su eBay e Amazon. La Figura 9-7 mostra una
valigetta di plastica con una serie completa di moduli (37 tipi diversi: l’ultimo settore contiene due moduli diversi). Tabella 9-1 - Un elenco parziale di rivenditori e produttori di moduli sensore e di output.
Nome
URL
Adafruit
www.adafruit.com
CuteDigi
store.cutedigi.com
DealeXtreme (DX)
www.dx.com
KEYES
en.keyes-robot.com
SainSmart
www.sainsmart.com
Seeed Studio
www.seeedstudio.com
TinyCircuits
www.tiny-circuits.com
Trossen Robotics
www.trossenrobotics.com
Vetco
www.vetco.net
Figura 9-7 - Una serie di moduli di input/output.
Quasi tutti i rivenditori elencati nella Tabella 9-1 vendono anche moduli singoli, oltre a ponticelli, cavi di interconnessione e componenti di input e output. Potete comprare praticamente tutti i moduli di cui avete bisogno in piccole quantità, anche se non tutti i
moduli presenti nei kit possono essere disponibili da acquistare individualmente.
Le descrizioni dei moduli In questo paragrafo elencheremo i moduli di tre marche: KEYES, SainSmart e TinkerKit. Le descrizioni sono, per necessità, brevi. Qui l’accento è posto soprattutto sulla forma fisica e sulle connessioni elettriche dei moduli elencati nelle tabelle. “I sensori” a pagina 312 descrive i sensori componenti (cioè i sensori che compongono il kit) in maggiore dettaglio e, dove necessario, i moduli presentano riferimenti incrociati alle descrizioni dettagliate. Dopo aver lavorato con diversi moduli per un po’, potete cominciare a notare che molti dei moduli descritti qui utilizzano lo stesso circuito di base. Questo di solito consiste di un comparatore LM393 e di un sensore di qualche tipo. In tutti i casi, un potenziometro imposta la tensione di soglia e l’output dell’LM393 è collegato al pin del segnale del modulo. I moduli KEYES con circuiti simili sono elencati nella Tabella 9-2 e i moduli SainSmart con circuiti simili sono elencati nella Tabella 9-3. Tabella 9-2 - I moduli KEYES con circuiti simili (Figura 9-8).
Modulo
Nome
KY-025
Modulo interruttore reed
KY-026
Sensore di fiamma
KY-036
Sensore a contatto conduttivo
KY-037
Sensore con microfono sensibile
KY-038
Sensore con microfono
Tabella 9-3 - I moduli SainSmart con circuiti simili (Figura 9-8).
Modulo
Nome
20-011-981
Sensore fotosensibile
20-011-982
Sensore di vibrazioni/shock
20-011-983
Sensore a effetto hall
20-011-984
Sensore di fiamma
La Figura 9-8 mostra una rappresentazione schematica e generica del circuito comparatore LM393 utilizzato nei moduli elencati nella Tabella 9-2 e nella Tabella 9-3. I valori esatti del componente possono variare leggermente, ma lo stesso circuito di base viene utilizzato in diversi moduli. La differenza principale tra i moduli è il sensore (fiamma
IR, microfono, LDR, ecc.).
Figura 9-8 - Circuito generico dei moduli con IC comparatore.
Il terminale DO (digital output) proviene direttamente dal comparatore. È high quando l’input non invertente (+) è maggiore di quello invertente (–). L’output del comparatore diventa low se l’input non invertente è più basso di quello invertente. Alcuni moduli possono essere progettati con gli input per l’IC del comparatore organizzati al contrario rispetto a quello che si vede nella Figura 9-8, ma il principio di funzionamento è lo stesso. La tensione sull’input non invertente è impostata dal potenziometro. Questo costituisce la metà di un partitore di tensione che insieme al sensore e forse ad una resistenza limitatrice di corrente, forma l’altra metà. Un secondo partitore di tensione serve ad applicare circa la metà del VCC +5 V all’input invertente, o circa 2,5 V. Questo è l’input di riferimento. Il potenziometro si utilizza per impostare la tensione alla quale il comparatore cambierà il suo output, mentre il sensore cambia la sua resistenza in risposta a qualche tipo di input. Sull’estremità dell’output del circuito, si utilizza una resistenza da 10K come pull-up sul pin di output dell’IC. L’AO (analog output) è il valore “crudo” fornito dal sensore presso l’input dell’IC LM393 (in questo caso). Su questi moduli dotati di un solo output, soltanto l’output del comparatore è collegato al pin del terminale come il segnale DO. Un modulo può anche presentare un LED che indichi quando è presente l’alimentazione e qualche altro LED che indichi quando l’output del comparatore è low (diventa una fonte di alimentazione per il LED). Come tutto questo si relaziona con un sensore dipende da come il sensore risponde all’input e per farsi un’idea di come si comporta può rendersi necessario fare qualche esperimento. In molti casi, un sensore attivo rivela una resistenza diminuita, cosa che
farà sì che l’input non invertente scenda al si sotto della tensione di riferimento sull’input invertente. Quando questo accade, l’output del circuito comparatore mostrato nella Figura 9-8 diventa low e il LED sull’output dell’IC diventa attivo (l’IC funge da fonte di alimentazione per il LED). I circuiti comparatore che presentano un output low quando l’input si trova in uno stato attivo o al di sotto di una qualche soglia vengono detti circuiti active-low. In questi circuiti, una tensione bassa sull’output è equivalente a una condizione true. I circuiti che presentano un output high quando il sensore è attivo o l’input si trova al di sopra di una qualche soglia vengono detti circuiti active-high. In un circuito active-high, un output high è equivalente a una condizione true. True e false in questo senso significano semplicemente e rispettivamente che il sensore sta ricevendo input oppure no. ATTENZIONE Vi conviene dedicare qualche istante, armati di un DMM (multimetro digitale) e di una lente di ingrandimento, a esaminare con attenzione un modulo prima di collegarlo ad Arduino. Questo si rivela particolarmente importante nel caso dei moduli molto economici, dove ho trovato che mancano parti o appaiono ponti di saldatura (cortocircuiti) tra piazzole e pin di collegamento che non vanno da nessuna parte. Un modulo che ho esaminato aveva un pezzo di filo, installato dalla fabbrica, saldato tra tracce collegate ai pin +5 V e messa a terra! Questo avrebbe causato dei problemi. Il semplice fatto che un modulo sia dotato di pin per la messa a terra, +5 V e segnale non significa che tutti i pin siano effettivamente utilizzati e nemmeno che i pin facciano quello che implicano i nomi che sono stati loro assegnati. Una volta risolti tutti i problemi, i moduli tendono a funzionare bene (tutto sommato, sono formati soltanto da una manciata di componenti). Se prendete appunti, più tardi vi risparmierete qualche mal di testa.
Molti moduli comuni progettati dalla società cinese Shenzhen KEYES DIY Robot Co. Ltd. (conosciuta anche come semplicemente KEYES) sono venduti come singole unità oppure riuniti in kit di moduli, di solito con 36 moduli circa per kit. Potete trovare anche moduli che presentano le lettere “HXJ”. Funzionalmente, sono identici ai moduli KEYES, ma il layout della PCB può essere leggermente differente. La Tabella 9-4 è un elenco riassuntivo dei moduli KEYES descritti in questo paragrafo, mentre la Tabella 9-7 contiene immagini, note e diagrammi del pinout, da KY-001 a KY040. Alcuni dei modelli mostrati sono KEYES e alcuni sono di altri rivenditori, ma sono altrimenti identici (le unità HXJ, per esempio). Tutti condividono lo stesso pinout e le stesse funzioni e spesso hanno lo stesso nome (KY-002, KY-027 e così via). Notate che i moduli KY-007, KY-014, KY-029 o KY-030 non esistono. Non ho idea del perché. Tabella 9-4 - I moduli I/O KEYES più diffusi.
Numero di componente
Nome
KY-001
Sensore di temperatura
KY-002
Sensore di vibrazioni
KY-003
Sensore di campo magnetico a effetto hall
KY-004
Pulsante
KY-005
Emettitore di infrarossi
KY-006
Cicalino passivo
KY-008
LED laser
KY-009
LED RGB a colori
KY-010
Interruttore ottico
KY-011
LED a 2 colori
KY-012
Cicalino attivo
KY-013
Sensore analogico di temperatura
KY-015
Sensore di temperatura e umidità
KY-016
LED RGB a 3 colori
KY-017
Interruttore a inclinazione al mercurio
KY-018
Modulo LDR
KY-019
Relè 5 V
KY-020
Interruttore a inclinazione
KY-021
Mini interruttore reed
KY-022
Sensore/ricevitore di infrarossi
KY-023
Joystick a 2 assi
KY-024
Sensore lineare a effetto hall
KY-025
Modulo interruttore reed
KY-026
Sensore di fiamma
KY-027
Modulo luce magica
KY-028
Sensore di temperatura
KY-031
Sensore di shock
KY-032
Sensore di prossimità IR
KY-033
Sensore IR per seguire una linea
KY-034
LED a colori con lampeggiamento automatico
KY-035
Sensore magnetico a effetto hall
KY-036
Sensore di tocco
KY-037
Sensore con microfono sensibile
KY-038
Sensore con microfono
KY-039
Sensore del battito cardiaco con LED
KY-040
Encoder rotativo
Un altro produttore di moduli sensore è SainSmart. La Tabella 9-5 è un riepilogo di quello che si può trovare nella forma di kit di moduli di SainSmart e la Tabella 9-8 contiene immagini, note e diagrammi del pinout. Si tratta di un elenco rappresentativo, dal momento che i contenuti dei kit possono variare. I moduli con un numero di componente di SainSmart Part possono essere acquistati anche singolarmente e alcuni di loro sono unici. Tabella 9-5 - I moduli SainSmart disponibili nella forma di kit.
Numero di componente n/d
Nome Modulo relè
20-011-985
Sensore di tocco
20-019-100
Sensore di distanza a ultrasuoni HC-SR04
20-011-984
Sensore di fiamma
20-011-986
Sensore di temperatura e umidità relativa
n/d
Cicalino attivo
20-011-982
Sensore di vibrazioni/shock
n/d
Cicalino passivo
20-011-987
Sensore di tracking
20-011-983
Sensore a effetto hall
20-011-981
Sensore fotosensibile
n/d
Ricevitore di infrarossi
20-011-944
Modulo joystick
20-011-946
Sensore d’acqua
Infine, ci sono i moduli TinkerKit. La Tabella 9-6 è un riepilogo e la Tabella 9-9 rivela i dettagli su ciascuno dei moduli inclusi nel kit “Pro”. La serie di moduli TinkerKit è progettata per lavorare con la shield di interfaccia di TinkerKit (descritta nel Capitolo 8). Anche se attualmente la società TinkerKit non è attiva, i suoi prodotti si trovano ancora presso http://www.mouser.com), Newark/Element14 (http://www.newark.com) e altri. Le librerie software si trovano su GitHub (https://github.com/TinkerKit). Una serie di schede tecniche di base relative a questi moduli si trovano presso Mouser (http://bit.ly/mouser-tinkerkit). Tabella 9-6 - Riepilogo dei moduli TinkerKit.
Modulo
Nome
Modulo
Nome
T000020
Modulo accelerometro
T010020
Modulo mosfet
T000030
Modulo joystick
T010110
Modulo LED ad alta intensità
T000070
Sensore a effetto hall
T010111
Modulo LED blu 5 mm
T000090
Modulo LDR
T010112
Modulo LED verde 5 mm
T000140
Modulo potenziometro rotativo
T010113
Modulo LED giallo 5 mm
T000150
Modulo potenziometro lineare
T010114
Modulo LED rosso 5 mm
T000180
Modulo pulsante
T010115
Modulo LED blu 10 mm
T000190
Modulo inclinazione
T010116
Modulo LED verde 10 mm
T000200
Modulo termistore
T010117
Modulo LED giallo 10 mm
T000220
Modulo sensore di tocco
T010118
Modulo LED rosso 10 mm
La Tabella 9-9 non mostra i diagrammi del pinout perché i moduli TinkerKit utilizzano tutti un pinout standard. L’unica differenza tra i moduli è tra i moduli discreti digitali (on/ off) e analogici. Entrambi i tipi utilizzano lo stesso pinout di base mostrato nella Figura 9-9.
Figura 9-9 - Il connettore comune dei moduli TinkerKit.
I circuiti dei moduli TinkerKit gestiscono l’interfaccia elettrica, che può rilevare il livello, amplificarlo e così via. Quindi dovete tenere presente che, nel caso di molti dei moduli TinkerKit, Arduino non comunica direttamente con il sensore, il LED, il controllo
dell’input, o il dispositivo di output, ma piuttosto con un circuito di interfaccia. Se girate un modulo, potete controllarne la parte posteriore per vedere quale circuito vi è installato. Perfino i moduli LED hanno installato un transistor. L’obiettivo dei prodotti di TinkerKit era creare qualcosa che fosse facile da collegare ad Arduino e relativamente insensibile agli errori meno gravi e quindi alcune delle funzionalità di integrazione dell’interfaccia di basso livello sono già fornite.
I moduli KEYES Tabella 9-7 - I moduli sensore e di output di tipo KEYES.
Numero del componente
Nome e descrizione
KY-001
Sensore di temperatura Utilizza un IC del sensore di temperatura DS18B20 da un solo filo in un package TO-92.
KY-002
Sensore di vibrazioni Un sensore di shock sigillato chiude il circuito tra i pin GND e signal. +5 V non sembra essere collegato, ma c’è una posizione per una resistenza sul lato inferiore della PCB. Molto sensibile.
KY-003
Sensore di campo magnetico a effetto hall Rileva la presenza di un campo magnetico. L’output è il collettore aperto di un transistor NPN nel dispositivo A3144 a effetto hall. L’output è collegato alla messa a terra quando il sensore è attivo. Non si tratta di un sensore lineare, mentre il KY-024 lo è.
KY-004
Pulsante Un semplice interruttore a pulsante. L’output diventa low quando il pulsante è premuto. Emettitore di infrarossi Un LED IR adatto per essere utilizzato con un KY-022.
Immagine
Pinout
KY-005
Notate che si deve utilizzare una resistenza esterna che limiti la tensione. Sul modulo testato, il pin GND non era collegato.
KY-006
Cicalino passivo Si tratta di un piccolo altoparlante con un diaframma metallico. Il pin +5 V non è utilizzato.
KY-008
LED laser Un LED laser 650 nm (rosso) a bassa potenza (vedere Figura 9-51). La messa a terra è collegata all’anodo, il segnale al catodo. Il pin+5 V non è utilizzato (ma è collegato al segnale per mezzo di una resistenza da 10K sulla PCB). L’unità ha bisogno di una resistenza esterna che limiti la tensione.
KY-009
LED RGB a 3 colori Utilizza un LED con output simultanei rosso, verde o blu. Diversi moduli testati hanno pinout diversi e quindi prima vi conviene controllare come è collegato ciascun colore.
KY-010
Interruttore ottico Incorpora un interruttore ottico (un LED e un fototransistor) per rilevare quando un oggetto si trova nello spazio tra le due sezioni verticali. LED a 2 colori Utilizza un LED capace di emettere output verde o rosso o entrambi contemporaneamente. Si tratta
KY-011
di un componente con tre terminali, che significa che i LED interni condividono un collegamento comune e che ciascuno può essere gestito in modo indipendente.
KY-012
Cicalino attivo Genera un tono di un’altezza fissa quando gli si fornisce alimentazione.
KY-013
Sensore analogico di temperatura Come elemento attivo per rilevare la temperatura, utilizza un termistore (vedere “I termistori” a pagina 315). La tensione di output varia in funzione della temperatura.
KY-015
Sensore di temperatura e umidità Utilizza un sensore di temperatura e umidità DHT11. Trovate ulteriori informazioni su questo componente in “I sensori DHT11 e DHT22” a pagina 313.
KY-016
LED RGB a 3 colori Fondamentalmente uguale al KY-009, ma utilizza un componente through-hole anziché un dispositivo a montaggio superficiale. Interruttore a inclinazione al mercurio Rileva l’inclinazione su un asse utilizzando una gocciolina di mercurio in un tubo di vetro (vedere “I sensori di inclinazione a un solo asse” a pagina 319). Per rilevare
KY-017
l’inclinazione su due assi, si devono utilizzare due di questi moduli. Il pin +5 V non è collegato al sensore, ma è collegato al pin signal per mezzo di un LED e di una resistenza da 680 ohm.
KY-018
Modulo LDR Un modulo LDR (lightdependent resistor). La tensione di output varia quando varia la quantità di luce che colpisce l’LDR (vedere “Le fotocellule” a pagina 321).
KY-019
Relè da 5 V Un piccolo relè montato su PCB (vedere “I relè” a pagina 341) con un driver integrato per interfacciarsi con un segnale di controllo del livello logico.
KY-020
Interruttore a inclinazione Simile al KY-017, ma utilizza una pallina di metallo all’interno di una piccola scatola.
KY-021
Mini interruttore reed Un interruttore reed racchiuso in un piccolo tubo di vetro che si chiude in presenza di un campo magnetico.
KY-022
Sensore/ricevitore di infrarossi Un sensore a infrarossi 1838 come quelli che si utilizzano per i telecomandi dei televisori e altri elettrodomestici. Opera ad una frequenza portante di 37,9 kHz. La presenza del vettore di IR fa sì che l’output diventi
high.
KY-023
Joystick a 2 assi Contiene due potenziometri montati ad angolo retto l’uno rispetto all’altro per rilevare il movimento x–y dell’albero centrale.
KY-024
Sensore lineare a effetto hall Utilizza un sensore lineare SS49E a effetto hall. Per regolare la sensibilità del circuito, con un potenziometro si utilizza un comparatore di tensione LM393.
KY-025
Modulo interruttore reed Utilizza un interruttore reed e il circuito comparatore mostrato nella Figura 9-8.
KY-026
Sensore di fiamma Utilizza un sensore ottimizzato per lunghezze d’onda IR tra 760 e 1100 nm. Il livello di sensibilità è impostato da un potenziometro.
KY-027
Modulo luce magica A essere onesti, non capisco bene per che cosa lo si dovrebbe utilizzare. Il KY-027 è fondamentalmente un KY-017 con un LED su un circuito separato.
KY-028
Sensore di temperatura Utilizza un termistore e un IC comparatore per rilevare una soglia (vedere “I termistori” a pagina 315). Il punto della soglia è impostato dal potenziometro. Sensore di shock (impatto)
KY-031
Rileva un impatto improvviso e genera un output. Non rileva l’inclinazione come il KY-002, il KY-017 e il KY-020.
KY-032
Sensore IR di prossimità Utilizza il riflesso di una luce a infrarossi per rilevare una superficie o un ostacolo che si trovano nei suoi pressi. La sensibilità è impostata dal potenziometro. Notate che esistono almeno due varianti di questo modulo. Controllate il pinout prima di fornire l’alimentazione.
KY-033
Sensore IR per seguire una linea Utilizza il riflesso di una luce a infrarossi su una superficie per rilevare la differenza tra luce e oscurità. Generalmente lo si utilizza per creare un robot che segua una linea scura su una superficie bianca. La sensibilità è impostata dal potenziometro. Fondamentalmente uguale al KY-032 ma con il LED e il sensore IR montati sulla parte inferiore della PCB.
KY-034
LED a colori con lampeggiamento automatico Un LED lampeggia automaticamente quando gli viene fornita alimentazione.
KY-035
Sensore magnetico a effetto hall Simile al KY-003 ma con un sensore lineare a effetto hall SS49E. Sensore di contatto conduttivo
KY-036
L’output cambia quando qualcosa di conduttivo (come un dito) tocca il piombo del sensore.
KY-037
Sensore con microfono sensibile Un microfono con una soglia variabile. Il microfono più grande (rispetto a quello del modulo KY-038) dota questa unità di un livello leggermente maggiore di sensibilità.
KY-038
Sensore con microfono Un microfono con una soglia variabile. Per via delle dimensioni più ridotte del microfono (rispetto a quello del modulo KY-037), questo modulo è meno sensibile.
KY-039
Sensore del battito cardiaco con LED Fondamentalmente, è come lo strumento molto diffuso negli ospedali e negli studi medici che serve a misurare il ritmo cardiaco dei pazienti. Per rilevare le leggere variazioni di luce di un LED che riflettono il fluire del sangue in un dito, si utilizza un fototransistor.
KY-040
Encoder rotativo Un encoder rotativo digitale e continuo. Trovate maggiori informazioni su questi dispositivi in “Gli encoder rotativi digitali” a pagina 330.
I moduli SainSmart Tabella 9-8 - I moduli sensore e di output di SainSmart.
Numero del componente
Nome e descrizione Modulo relè Relè da 5 V con contatti da 10 A.
20-019-100
Sensore di distanza a ultrasuoni HC-SR04 Utilizza un paio di trasduttori a ultrasuoni per emettere un segnale e quindi riceverne l’eco. Il tempo trascorso tra la prima emissione e l’eco è proporzionale alla distanza tra il sensore e la superficie che riflette il segnale. Cicalino attivo Emette un tono quando gli si fornisce alimentazione. Cicalino passivo Risponde a un input di onde quadre, che permette a questo modulo di emettere un tono programmabile.
20-011-983
Sensore a effetto hall Utilizza un sensore lineare a effetto hall. La soglia della sensibilità è impostata dal piccolo potenziometro. Ricevitore di infrarossi Risponde agli impulsi provenienti da un telecomando per generare un segnale digitale.
20-011-946
Sensore d’acqua Rileva la presenza d’acqua rispondendo ai cambiamenti della conduttività sulle dita metalliche della PCB. Può essere utilizzato per rilevare
Immagine
Pinout
pioggia o spruzzi.
20-011-985
Sensore di tocco Rileva il tocco di un dito
20-011-984
Sensore di fiamma Risponde a IR tra 760 e 1100 nm. La sensibilità è impostata dal potenziometro.
20-011-988
Sensore di temperatura Utilizza un IC per sensore di temperatura da un filo DS18B20 (vedere “DS18B20” a pagina 312 in un package TO-92.
20-011-986
Sensore di temperatura e umidità relativa Utilizza un sensore di temperatura e umidità DHT11. Trovate ulteriori informazioni su questo componente nella Figura 9-14.
20-011-982
Sensore di vibrazioni/shock Percepisce movimenti improvvisi (shock o vibrazioni) con un sensore sigillato, simile al KY-002 di KEYES.
20-011-987
Sensore per il tracking Utilizza un LED IR LED e un fotosensore per rilevare la rilfettanza.
20-011-981
Sensore fotosensibile Un circuito LDR di base (vedere “Le fotocellule” a pagina 321) con sensibilità variabile.
20-011-944
Modulo joystick Un joystick con potenziometro lineare da due assi. Include
una grande manopola.
I moduli TinkerKit Tabella 9-9 - I moduli I/O TinkerKit.
Numero del componente
Nome e descrizione
T000020
Modulo accelerometro Basato sull’IC LIS344AL da tre assi. Include due amplificatori di segnale.
T000030
Modulo joystick Due potenziometri montati su una sospensione cardanica da due assi.
T000070
Sensore a effetto hall Emette un output relativo alla tensione che dipende dalla potenza di un campo magnetico locale.
T000090
Modulo LDR LDR (light-dependent resistor) con un amplificatore, emette come output una tensione proporzionale al livello della luce.
T000140
Modulo potenziometro rotativo Potenziometro analogico rotativo da 4,7 kohm.
T000150
Modulo potenziometro lineare Potenziometro analogico lineare (slider) da 4,7 kohm.
T000180
Modulo pulsante Semplice modulo pulsante, normalmente aperto, che emette +5 V quando è premuto.
Immagine
T000190
Modulo inclinazione Utilizza un semplice sensore di inclinazione con una pallina metallica interna.
T000200
Modulo termistore Utilizza un termistore e un amplificatore per emettere una tensione proporzionale alla temperatura.
T000220
Modulo sensore di tocco Utilizza un controllo di tocco singolo QT100A per produrre 5 V quando viene toccato il sensore. La parte tattile è quella sulla parte superiore della PCB, che nell’immagine appare piatta.
T010010
Modulo relè Incorpora un relè da 5 V con contatti da 250 V 10 A, un transistor e un blocco di terminali del tipo a vite.
T010020
Modulo mosfet Passa fino a 24 V DC utilizzando un MOSFET IRF520. Abbastanza veloce da poter essere utilizzato con PWM per il controllo di motori DC.
T010110
Modulo LED ad alta intensità Fornisce cinque LED ad alta luminosità. Richiede molta corrente e quindi potete preferire utilizzarlo con un T010020 e un alimentatore esterno.
T010111
LED blu 5 mm Un modulo semplice con un solo LED blu da 5 mm.
T010112
Modulo LED verde 5 mm Un modulo semplice con un solo LED verde da 5 mm.
T010113
Modulo LED giallo 5 mm Un modulo semplice con un solo LED giallo da 5 mm.
T010114
Modulo LED rosso 5 mm Un modulo semplice con un solo LED rosso da 5 mm.
T010115
Modulo LED blu 10 mm Un modulo semplice con un solo LED blu grande 10 mm.
T010116
Modulo LED verde 10 mm Un modulo semplice con un solo LED verde grande 10 mm.
T010117
Modulo LED giallo 10 mm Un modulo semplice con un solo LED giallo grande 10 mm.
T010118
Modulo LED 10 rosso mm Un modulo semplice con un solo LED rosso grande 10 mm.
I moduli Grove SeedStudio ha riunito un gran numero di moduli sotto il sistema di interconnessione Grove. Dal punto di vista della funzionalità, molti di questi sono simili ai moduli messi a disposizione da KEYES, SainSmart e TinkerKit. Altri sono prodotti unici della linea Grove. I moduli Grove sono categorizzati in sei gruppi: monitoraggio ambientale, rilevamento del movimento, interfaccia utente, monitoraggio fisico, funzioni delle porte logiche e controllo dell’alimentazione. Tutti i moduli utilizzano uno schema di connessione standardizzato che utilizza un connettore modulare da 4 pin con le linee per alimentazione, messa a terra e segnale.
Come nel caso dei moduli TinkerKit, il vantaggio offerto dai moduli Grove è che vi evitano di dover fare delle prove per verificare (o scoprire) che cosa fanno realmente i loro pin. Una shield che segue le convenzioni Grove (come le shield Grove che abbiamo visto nel Capitolo 8) si collegano ai moduli sensore o attuatore Grove utilizzando un cavo già pronto. Inoltre, Seeed Studio vende cavi già preparati per collegare i moduli a una shield di interfaccia o di controllo. Una funzionalità dei moduli Grove che io trovo molto affascinante è l’inclusione di linguette di montaggio nella PCB della maggior parte dei moduli. Questo permette di lasciare l’hardware di montaggio separato dai circuiti (cosa che non accade quando ci sono fori di montaggio nel mezzo del layout della PCB) e i connettori modulari sono facili da utilizzare. Un esempio di modulo Grove è mostrato nella Figura 9-10.
Figura 9-10 - Un esempio di modulo Grove.
Mentre scrivevo questo libro, i moduli TinkerKit stavano sparendo, mentre i moduli Grove sembravano essere in piena forma. Questo non significa che TinkerKit non tornerà sulla scena o che Grove esisterà per sempre: nel mondo di Arduino le cose cambiano molto in fretta. Come vi ho fatto notare in precedenza, questo capitolo e il Capitolo 8 sono pensati per fornire esempi di quello che è disponibile e non per indicare riferimenti definitivi. Il mercato è troppo volatile per permettere di farlo. Se state cercando dei moduli che seguono una convenzione di un tipo o di un altro, vi consiglio di dare un’occhiata ai prodotti Grove. Se volete utilizzare una shield d’espansione o di interfaccia diversa, potete creare dei cavi di interfaccia personalizzati utilizzando shell, pin e prese già pronti, come descritto in “Costruire connettori personalizzati” a pagina 355. Trovate un elenco completo dei moduli attualmente disponibili sulla wiki di Seeed Studio (http://bit.ly/seeed-grove).
Descrizioni di sensori e moduli Il resto di questo capitolo descrive alcuni dei vari tipi di componenti, moduli e sensori compatibili con Arduino esistenti attualmente. Dico “alcuni dei” perché, come nel caso
delle shield, appaiono continuamente nuovi sensori e moduli e alcuni tipi più vecchi spariscono se non c’è mercato sufficiente per giustificarne la produzione continua. Alcuni moduli sono tipi piuttosto specializzati, come sensori di gas o controlli di corrente. Alcuni sensori possono sparire quando vengono sostituiti da tipi più moderni. Potete trovare tutti i dispositivi descritti qui e molti altri facendo pochissima fatica, utilizzando Google, consultando gli elenchi di Amazon.com oppure i siti web elencati in “Fonti” a pagina 357. La Tabella 9-10 elenca i controlli, i sensori, gli attuatori, i display e i moduli descritti in questo paragrafo. Sono organizzati in base a funzione, classe (input o output) e tipo (dispositivo, componente o modulo). Ricordate che i componenti di ciascun modulo sono disponibili anche come prodotti singoli e quindi potete creare i vostri moduli personalizzati o incorporare i componenti in qualcos’altro. Tabella 9-10 - Indice di sensori e moduli.
Funzione
Classe
Tipo
Descrizione
Audio
Output
Dispositivo
Cicalino (annunciatore), componenti e moduli
Audio
Sensore
Microfono
Moduli pick-up audio (microfono)
Comunicazione
I/O
Modulo
Moduli RF 315/433 MHz
Comunicazione
I/O
Modulo
Moduli wireless APC220
Comunicazione
I/O
Modulo
Ricetrasmittente WiFi ESP8266
Comunicazione
I/O
Modulo
Modulo NRF24L01
Contatto
Sensore
Interruttore
Moduli interruttore a contatto
Contatto
Output
Interruttore
Relè e moduli relè
Controllo
Input
Dispositivo
Tastierini numerici
Controllo
Input
Modulo
Moduli joystick
Controllo
Input
Dispositivo
Potenziometri
Display
Output
Modulo
Moduli a 7 segmenti
Display
Output
Modulo
Display LCD ERM1601SBS-2 16 × 1
Display
Output
Modulo
Display LCD ST7066 (HD44780) 16 × 2
Display
Output
Modulo
Display LCD ERC240128SBS-1 240 × 128
Display
Output
Modulo
Display TFT ST7735R 128 × 160
Emissione di luce
Output
Display
Display LED a 7segmenti
Emissione di luce
Output
Display
Emissione di luce
Output
Laser
Emissione di luce
Output
LED
LED di un solo colore
Emissione di luce
Output
LED
LED bicolori
Emissione di luce
Output
LED
LED tricolori (RGB)
Rilevamento della luce
Sensore
Photocell
Rilevamento della luce
Sensore
Diode
Rilevamento della luce
Sensore
Transistor
Moduli fototransistor
Rilevamento IR
Sensore
IR
Moduli sensore PIR
Magnetico
Sensore
Stato solido
Moduli sensore a effetto hall
Magnetico
Sensore
Stato solido
Moduli magnetometro
Umidità
Sensore
PCB
Movimento
Output
Attuatore
Controllo motori DC
Movimento
Output
Attuatore
Controllo servo
Movimento
Output
Attuatore
Controllo motori passo-passo
Movimento
Sensore
Stato solido
Moduli giroscopio
Movimento
Sensore
Stato solido
Moduli accelerometro
Pressione
Sensore
Stato solido
Moduli sensore barometrico
Intervallo
Sensore
Modulo
Moduli trasmettitore/ricevitore laser
Intervallo
Sensore
Modulo
Moduli sensore oggetto LED
Intervallo
Sensore
Modulo
Moduli misurazione della distanza a ultrasuoni
Rotazione
Sensore
Controllo
Output
Modulo
Temperatura
Sensore
Stato solido
Moduli sensore di temperatura DS18B20
Temperatura
Sensore
Modulo
Moduli sensore temperatura e umidità DHT11/DHT22
Segnale
Moduli matrice di LED LED laser
Moduli LDR Moduli fotodiodo
Moduli sensore umidità del suolo
Moduli encoder rotativo digitale Moduli generatore di forme d’onda
Moduli sensore di temperatura
Temperatura
Sensore
Modulo
Inclinazione
Sensore
Interruttore
Moduli sensore di inclinazione un solo asse
Inclinazione
Sensore
Interruttore
Moduli sensore di inclinazione due assi
Tempo
Supporto
Modulo
Moduli RTC DS1302
Tempo
Supporto
Modulo
Moduli RTC DS1307
Tempo
Supporto
Modulo
Moduli RTC DS3231
Tempo
Supporto
Modulo
Moduli RTC PCF8563
Output
Modulo
Moduli DAC
Sensore
PCB
Tensione Acqua
termistore
Moduli sensore conduttività dell’acqua
I sensori Anche se è possibile collegare molti sensori direttamente a un Arduino, i moduli come quelli elencati nel paragrafo precedente sono definitivamente più facili da gestire. Ma i moduli possono non rappresentare una buona scelta se volete creare hardware personalizzato per un’applicazione specifica. In quel caso, vi conviene utilizzare soltanto il componente sensore e collocarlo esattamente dove è necessario. Un sensore è sempre un dispositivo di input che acquisisce dati dall’ambiente fisico e li converte in una forma che un microcontroller possa elaborare. Come implica il nome, “sentono” qualcosa, dove quel qualcosa può essere temperatura, umidità, campi magnetici, luce visibile, calore, infrarossi, suono o movimento fisico.
I sensori di temperatura, umidità e pressione Esistono diversi tipi di sensori ambientali che possono essere utilizzati con Arduino. Che si tratti di semplici sensori di rilevamento dell’acqua basati sulla continuità o di sensori sensibili a temperatura e umidità, è molto probabile che si trovi un sensore capace di misurare quanto è caldo o freddo o umido o secco l’ambiente.
DS18B20 Il DS18B20 è un sensore di temperatura cosiddetto “a un filo” che restituisce al sensore un flusso di dati binari che contiene la temperatura. La Figura 9-11 mostra un modulo facile da trovare con un DS18B20, alcuni componenti passivi e un LED.
Figura 9-11 - Un tipico modulo DS18B20.
La Figura 9-12 mostra il modulo montato su una shield di prototipazione con un relè e un potenziometro. Questo, a proposito, è un semplice termostato digitale che è stato montato per sostituire il termostato elettromeccanico bimetallico ormai morto di una piccola stufa elettrica portatile. Il termostato meccanico del vecchio stile non aveva mai funzionato molto bene, ma con questa semplice sostituzione digitale fa il suo lavoro in modo eccellente. La scheda Arduino cui si collega fornisce anche la possibilità di registrare i dati relativi alla temperatura ed eseguire altre funzioni. Una stufa economica di Internet delle Cose? Certo, perché no?
Figura 9-12 - Esempio di applicazione del modulo DS18B20.
I sensori DHT11 e DHT22 I sensori di temperatura e umidità DHT11 e DHT22 si presentano in package di plastica con tre terminali, come mostra la Figura 9-13. Si trovano anche montati su una piccola PCB, come mostra la Figura 9-14.
Figura 9-13 - Il package di DHT11.
Figura 9-14 - Il modulo DHT11/DHT22.
I sensori DHT11 e DHT22 presentano delle differenze per quanto riguarda la risoluzione e la velocità dei dati seriali. Il DHT11 è un dispositivo di base con una precisione di rilevamento della temperatura di +/– 2 gradi C e una risoluzione dell’umidità del +/– 5% di umidità relativa. Ha un intervallo di funzionamento compreso tra il 20 e il 90% di umidità relativa e 0 e 50 gradi C. Il DHT22 ha una risoluzione della temperatura di +/– 0,2 gradi C e una capacità di percezione dell’umidità relativa del +/– 1%, oltre a una velocità superiore di dati seriali. Il DHT22 ha un intervallo di percezione più ampio rispetto al DHT11: da –40 a 80 gradi C e dallo 0 al 100% di umidità relativa. Il pinout del DHT22 è identico a quello del DHT11. Sia il DHT11 che il DHT22 utilizzano un protocollo per le comunicazioni seriali a un filo e non standard. Funziona adottando un approccio segnale-risposta. Il microcontroller costringe la linea singola di segnale a rimanere low per un breve periodo di tempo e poi le permette di diventare high (per mezzo di una resistenza pull-up, aggiunta esternamente oppure presente sul modulo PCB). Il DHT11/ DHT22 risponde con 40 bit di dati seriali, organizzati come cinque valori di dati da 8 bit, compreso un checksum di 8 bit.
I termistori Un termistore è una resistenza controllata dalla temperatura. Ne esistono con coefficiente di temperatura negativo o positivo. Un dispositivo con coefficiente di
temperatura negativo (NTC, negative temperature coefficient) mostra una resistenza inferiore quando aumenta la temperatura. Un dispositivo con coefficiente di temperatura positivo (PTC, positive temperature coefficient) si comporta nel modo opposto. I termistori NTC sono il tipo più comune che si trova nei sensori e quelli del tipo PTC spesso si utilizzano come limitatori di corrente di spunto. La Figura 9-15 mostra un modo di collegare un termistore a un Arduino, ma attenzione che la curva di risposta del termistore non è lineare. Alcuni circuiti sostituiscono la resistenza fissa con una sorgente di tensione costante.
Figura 9-15 - Un semplice termistore collegato a un Arduino.
Anche se è possibile collegare un termistore direttamente a un Arduino, un modo più facile è utilizzare un modulo che includa i componenti passivi necessari per creare un partitore di tensione per il termistore, come il KY-028 mostrato nella Tabella 9-7. Potete anche utilizzare il circuito amplificatore operazionale mostrato nella Figura 9-26 per aumentare la sensibilità del termistore. Notate che, dal momento che la maggior parte dei termistori utilizzati per rilevare la temperatura sono di tipo NTC, la tensione che appare sull’input analogico di Arduino scende quando la temperature aumenta.
I sensori d’acqua Un sensore d’acqua è utile per molte applicazioni, da un sensore antiallagamento in una cantina a un rilevatore di pioggia per una stazione meteorologica automatica. La Tabella
9-8 mostra un tipo di rilevatore d’acqua disponibile presso SainSmart (il 20-011-946). Questo sensore incorpora un transistor NPN che mantiene l’output low quando le sottili tracce della PCB sono collegate da una goccia d’acqua, o fondamentalmente qualsiasi cosa abbastanza bagnata da far sì che il transistor conduca la corrente. La Figura 9-16 mostra lo schema di questo sensore. Come potete vedere, non è complicato e può essere utilizzato praticamente con qualsiasi sonda o filo conduttivo. Se collegate questo circuito a un paio di fili di acciaio e montate i fili in modo che stiano a circa un centimetro (o 1/4 di pollice) di distanza dal pavimento della cantina, potete utilizzarlo per azionare un allarme al piano di sopra quando l’acqua comincia ad allagare la cantina.
Figura 9-16 - Schema di un sensore d’acqua.
I sensori di umidità del suolo Nella sua forma più semplice, un sensore di umidità del suolo a due poli realmente non è nient’altro che una sonda di conduttività. La sonda è configurata in modo che si comporti come un componente di un semplice partitore di tensione e la tensione che appare attraverso di esso sarà una funzione della conduttività del suolo tra le sonde. Potete acquistare un kit composto da una sonda di umidità, un piccolo modulo di interfaccia e un cavo da fornitori come SainSmart. La Figura 9-17 mostra tutti i tre componenti di un kit del genere.
Figura 9-17 - Il kit della sonda per rilevare l’umidità del suolo con il modulo di interfaccia.
Lo stesso effetto può essere ottenuto utilizzando praticamente qualsiasi materiale conduttivo per le sonde. Per un utilizzo prolungato, l’acciaio inossidabile o delle barre di carbonio potrebbero rappresentare una scelta migliore, nei posti dove la corrosione può essere un problema, e un amplificatore o un buffer di qualche tipo è essenziale per ottenere letture omogenee senza perdere troppa corrente nella sonda (cosa che può provocare alcuni effetti collaterali interessanti e anche contribuire alla corrosione degli elettrodi della sonda). Un’altra variazione del sensore di umidità del suolo, il Grove 101020008 di Seeed Studio, è mostrata nella Figura 9-18. Questo sensore include un transistor NPN integrato sulla scheda per portare la caduta della tensione a un livello con il quale l’ADC AVR di Arduino possa lavorare. Lo strato di rame sui poli di questa sonda è stato placcato con un sottile stato d’oro per resistere alla corrosione.
Figura 9-18 - Una sonda per l’umidità del suolo.
Lo schema della sonda per l’umidità del suolo è mostrato nella Figura 9-19. Essenzialmente, il circuito è identico a quello utilizzato per il sensore d’acqua, mostrato nella Figura 9-16. Notate che questo design utilizza un connettore da quattro terminali anziché la connessione con pin utilizzata sulla sonda nella Figura 9-17. Questo è certamente più comodo, ma dovete fare attenzione a come sono collegati i terminali del connettore.
Figura 9-19 - Schema della sonda per l’umidità del suolo.
I sensori barometrici Con un sensore di pressione barometrica, come quello mostrato nella Figura 9-20, e i moduli DHT11 o DHT22 descritti prima (“I sensori DHT11 e DHT22” a pagina 313), si può utilizzare un Arduino per costruire una stazione meteorologia compatta. Il sensore mostrato qui si basa su un sensore MPL115A2 con un’interfaccia I2C.
Figura 9-20 - Un modulo sensore di pressione barometrica.
Questo specifico modulo non è abbastanza preciso da poter essere utilizzato come un altimetro, ma va bene per acquisire e registrare dati meteorologici. Altri moduli basati su sensori come il MPL3115A2 o il BMP085 sono abbastanza precisi da poter essere utilizzati come altimetri.
I sensori di inclinazione Di solito, un sensore di inclinazione non è niente più che una piccola capsula sigillata con una serie di contatti interni e una pallina di metallo o una perlina di mercurio al suo interno. Se il dispositivo viene spostato dal suo orientamento “neutro” (perpendicolare all’attrazione gravitazionale), la pallina o la perlina si muovono e chiudono un circuito tra i contatti. Il funzionamento è identico a quello di un interruttore che si chiude. Dovete tenere presente che un sensore di inclinazione non è un sensore proporzionale. È inclinato oppure no e quindi dal punto di vista elettrico è aperto oppure chiuso. Non ci sono opzioni intermedie.
I sensori di inclinazione a un solo asse La Figura 9-21 mostra un modulo con un sensore di inclinazione a perlina di mercurio, in questo caso un KY-017. Questo modulo in particolare rileva l’inclinazione soltanto in una direzione. Per rilevare l’inclinazione sulle due estremità di un asse, dovrete utilizzarne due o più.
Figura 9-21 - Un sensore di inclinazione a un solo asse.
I sensori di inclinazione a due assi La chiave per utilizzare un sensore di inclinazione in modo efficace è determinare la posizione neutra su un determinato asse. Una volta che si sa questo, il sensore può essere orientato in modo che rilevi l’inclinazione su un determinato asse orizzontale. La Figura 9-22 mostra due sensori di inclinazione su un’unica base per rilevare l’inclinazione sugli assi x e y. Notate che questa organizzazione rileva l’inclinazione soltanto in una direzione (che sia verso l’alto e verso il basso, a seconda di come sono montati).
Figura 9-22 - Un sensore di inclinazione a due assi.
Se volete rilevare l’inclinazione verso l’alto o verso il basso su entrambi gli assi, dovete organizzare quattro sensori di inclinazione con la giusta angolazione l’uno rispetto all’altro. In questo modo, potete rilevare l’inclinazione su entrambe le direzioni +/– x e +/– y. A differenza che nel caso dei giroscopi a stato solido (come quelli descritti in “I
giroscopi” a pagina 327), questo tipo di circuito non ha bisogno di un riferimento di partenza e funziona sempre purché esista la gravità. La controindicazione è che non ci sono passaggi intermedi: i sensori di inclinazione sono on oppure off.
I sensori audio Un microfono può essere utilizzato in diversi modi interessanti. Un modo è incorporare il microfono in un sistema di sicurezza per rilevare rumori forti come un vetro che viene rotto, qualcuno che dà un calcio a una porta o il suono di uno sparo. Se è abbastanza sensibile, può essere utilizzato perfino per rilevare passi. Un microfono a contatto può essere utilizzato per raccogliere dati diagnostici da un motore a combustione interna o perfino a un motore elettrico mentre è acceso. In questo modo, è possibile rilevare cuscinetti rumorosi e componenti allentati. Quando è combinato con un sensore ottico, un microfono omnidirezionale può essere utilizzato per costruire un rilevatore di fulmini (il tuono arriva circa 4 secondi dopo la luce per ciascun miglio di distanza dall’osservatore al fulmine). Esistono piccoli moduli dotati di microfoni e un IC, come quello mostrato nella Figura 923. Il minuscolo potenziometro serve a impostare la soglia del circuito. Questo modulo utilizza un circuito simile a quello mostrato nella Figura 9-8. È anche possibile collegare un microfono direttamente a uno degli input analogici di un Arduino, anche se non si ottiene nessun controllo sulla sua sensibilità. Per migliorarne la sensibilità si può utilizzare un semplice circuito amplificatore operazionale come quello mostrato nella Figura 9-26.
Figura 9-23 - Un modulo pick-up audio.
I sensori di luminosità
I sensori per rilevare la luminosità esistono in una vasta gamma di stili e tipi. Alcuni, come i sensori a infrarossi (IR), possono rilevare il calore. Altri rispondono agli IR emessi dalle fiamme, altri alla luce visibile. Un sensore di luminosità può utilizzare un elemento resistivo che cambia la sua resistenza intrinseca in risposta alla quantità di luce che lo tocca. Altri utilizzano un semiconduttore per fornire una sensibilità maggiore e una risposta rapida.
Le fotocellule Una fotocellula, nota anche come LDR (light-dependent resistor), è esattamente quello che dice il suo nome: un componente nel quale la resistenza cambia in funzione della quantità di luce che lo colpisce. Quasi tutti hanno un aspetto simile a quello mostrato nella Figura 9-24. Anche se questi dispositivi non sono tutti veloci come gli standard dei fotodiodi o dei fototransistor, tutti sono abbastanza veloci da poter trasportare audio in un fascio di luce modulato in ampiezza. Si rivelano utili come rilevatori del livello di luce ambientale, semplici collegamenti con dati ottici codificati con impulsi a bassa velocità, sensori guida perché un robot possa trovare una stazione di ricarica e rilevatori della posizione del sole per una matrice di pannelli solari.
Figura 9-24 - Un tipico dispositivo LDR economico.
I fotodiodi Anche se la maggior parte dei diodi sono dotati di un qualche grado di sensibilità alla luce, per ottenere questo effetto serve un fotodiodo. Un fotodiodo, come suggerisce il suo nome, è un diodo che è stato prodotto in modo che diventi conduttivo quando lo colpisce la luce e un tipo comune di fotodiodo è il diodo PIN. La “I” sta per lo strato di materiale silicio “intrinseco” tra le parti di silicio P e N del diodo e questo strato di materiale intrinseco rende un diodo PIN un ottimo rilevatore di luce. Dal momento che
rispondono molto velocemente, si rivelano utili per i collegamenti di comunicazione con dati ottici e come sensori di posizione per meccanismi rotativi. I diodi PIN si trovano anche in circuiti radio ad alta frequenza, dove fungono da interruttore. Per ulteriori informazioni sui diodi e altri dispositivi a stato solido, potete consultare l’Appendice D. La Figura 9-25 mostra come si collega un fotodiodo ad Arduino. Notate che il diodo è polarizzato inversamente: in altre parole, normalmente non conduce l’elettricità finché non viene esposto alla luce. Questo circuito funziona bene con una fonte di luce sufficientemente intensa, ma potrebbe trovare difficoltà in caso di condizioni di illuminazione scarse.
Figura 9-25 - La semplice connessione di un fotodiodo con Arduino.
Un modo per aumentarne la sensibilità è utilizzare una amplificatore operazionale, come mostra la Figura 9-26. In questo caso, si utilizza un amplificatore operazionale LM358 con un guadagno di circa 10 per fare in modo che la piccola tensione cambi quando il diodo arriva a un livello che l’ADC di Arduino può rilevare e convertire facilmente. Il potenziometro imposta il guadagno del circuito, in modo che possa essere regolato per adattarsi a una specifica applicazione. Questo circuito può essere assemblato facilmente su una piccola breadboard che non richiede saldature, oppure i componenti possono essere montati su una PCB di prototipazione (spesso detta “scheda millefiori”) per una sistemazione più permanente.
Figura 9-26 - Il collegamento di un fotodiodo con un amplificatore operazionale.
Potete consultare la selezione di fotodiodi (e di amplificatori operazionali) disponibili presso distributori di componenti elettronici come Digikey (http://www.digikey.com), Mouser (http://www.mouser.com) e Newark/Element14 (http://www.newark.com). Inoltre, molti fornitori di avanzi di magazzino hanno a portata di mano stock di fotodiodi.
I fototransistor Come suggerisce il nome, un fototransistor risponde alla luce variando la quantità di tensione che attraversa il dispositivo, proprio come farebbe altrimenti il terminale di input di base. Il circuito mostrato nella Figura 9-8 funziona con un fototransistor. Alcuni moduli, come il KY-039, si limitano a collegare i terminali del transistor ai pin del connettore (potete eliminare il LED e utilizzare il modulo come modulo sensore fototransistor, a proposito). Potete espandere il circuito di base aggiungendo un amplificatore operazionale per un maggiore guadagno. La Figura 9-27 mostra come si può fare. Andranno bene praticamente tutti i fototransistor NPN per giardinaggio, ma a me piace il BFH310, soprattutto perché l’ho trovato a ottimo prezzo in un grande sacco di cose (cercate presso un distributore di componenti elettronici come DigiKey o Mouser).
Figura 9-27 - Il circuito di un fototransistor con output sia analogici sia digitali.
Gli interruttori ottici comuni, come quello utilizzato nel modulo KY-010, utilizzano un fototransistor per rilevare l’output di un LED. Quando qualcosa blocca la luce entrando nello spazio vuoto del componente, il transistor smette di condurre la corrente. Anche gli isolatori ottici (detti anche optoaccoppiatori o optoisolatori) utilizzano un LED e un fototransistor per associale il segnale proveniente da un circuito all’altro senza bisogno di un collegamento elettrico diretto. Potete costruire il vostro accoppiatore con un LED, un fototransistor e un pezzo di tubo nero termoretraibile per coprire il tutto e proteggerlo dalla luce diretta.
I sensori PIR Un sensore PIR (passive infrared) misura la quantità di infrarossi nel suo campo visivo. Si utilizzano spesso nei sistemi di sicurezza perché di solito sono in grado di rilevare cambiamenti molto sottili nella “luminosità” IR ambientale di una stanza. Se il livello di IR si discosta dalla linea base dell’ambiente (come quando un essere umano, con il suo calore, entra nella stanza), il dispositivo emette un segnale. Un sensore PIR può essere utilizzato anche per ottenere una misurazione approssimativa della temperatura di qualsiasi cosa si trovi nel campo visivo. La Figura 9-28 mostra un modulo PIR piuttosto diffuso.
Figura 9-28 - Un rilevatore PIR.
Questo modulo è in vendita per circa 2 $ presso Banggood (http://www.banggood.com) e altri distributori. Utilizza tre connessioni: +5 V, messa a terra e output. L’output diventa high quando il sensore rileva un cambiamento negli IR dell’ambiente. Se combinate questo con un sensore audio, come quello mostrato nella Figura 9-23, con il codice di base per il sistema di sicurezza descritto nell’Esempio 5-5, otterrete un sistema di allarme anti intrusione perfetto.
I sensori magnetici Una delle aree dove la tecnologia dei semiconduttori ha fatto considerevoli passi avanti è quella del rilevamento dei campi magnetici statici. Rilevare un campo magnetico che oscilla, come quello prodotto da una molla, è relativamente facile, dal momento che non serve nient’altro che un’altra molla. Rilevare un campo magnetico statico, come quello che circonda sempre una calamita o il campo magnetico della Terra, è leggermente più difficile. Prima che venissero sviluppati i dispositivi elettronici, i sensori dei campi magnetici spesso incorporavano calamite, molle, specchi e altri componenti. Una normale bussola da campeggio è un esempio di tecnologia vecchio stile e funziona benissimo per andare a fare un’escursione oppure per rilevare il campo magnetico intorno a un filo che trasporta corrente continua diretta, ma utilizzarla per raccogliere dati si rivelerebbe molto noioso. Oggigiorno, è possibile costruire un rilevatore di campi magnetici o una bussola elettronica senza parti mobili che si interfacci direttamente con un microcontroller.
I sensori a effetto hall Un sensore a effetto hall è in grado di rilevare la presenza di un campo magnetico. Alcuni tipi, come l’A3144 utilizzato nel KY-003, sono pensati per essere dispositivi di tipo on/off: che rilevano se il campo magnetico è presente o meno. Altri tipi, come l’SS49E, sono tipi lineari, con un output analogico proporzionale relativo al campo magnetico rilevato. Il KY-024 è un esempio di un modulo con un sensore lineare a effetto hall. Sia
l’A3144 che l’SS49E hanno l’aspetto di piccoli transistor fatti di plastica e quindi qui non li mostrerò. Nel caso dell’A3144 e dispositivi simili, potete collegarlo direttamente a un Arduino, che è essenzialmente quello che fa il modulo KY-003. Il modulo KY-024 utilizza il circuito comparatore comune mostrato nella Figura 9-8.
I sensori magnetometro Un’altra forma di sensore magnetico che può rivelarsi utile con un Arduino è una bussola, come quella mostrata nella Figura 9-29. Questa unità di Adafruit utilizza un magnetometro HMC5883L da tre assi e un’interfaccia I2C.
Figura 9-29 - Un modulo bussola con magnetometro.
I sensori di vibrazioni e shock Di solito, i sensori di vibrazioni e shock si basano sul rilevamento del movimento in una massa di qualche tipo. Questa massa può essere un semplice braccio meccanico con una piccola massa sull’estremità e qualche contatto sistemato in modo che il braccio chiuda un circuito con uno o con l’altro quando si piega. Un’altra variazione potrebbe utilizzare un sensore ottico che cambi il suo stato di output quando il braccio interrompe un fascio di luce. Può anche trattarsi di una massa scorrevole con contatti, sensori ottici o perfino un sensore magnetico. Un altro tipo che viene utilizzato include un sensore piezoelettrico per rilevare il movimento in una massa. Un tipo molto economico di sensore di vibrazioni utilizza una piccola massa conduttiva in un contenitore sigillato. Quando la massa si muove, si rompe e fa contatto con le
maniche conduttive che si trovano su ciascuna estremità del contenitore. Il KY-020 è un tipico modulo con un sensore di questo tipo. Un sensore di shock è simile a un sensore di vibrazioni, ma in alcuni casi i sensori di shock sono progettati per rispondere a livelli di input specifici in termini di alcuni multipli di g (1g = la forza di gravità della Terra a livello del mare). Il KY-031 è un esempio di modulo sensore di shock a basso costo. Potete costruirvi un sensore di shock o di impatto utilizzando una pallina di metallo (una BB andrà bene), una molla (magari quella di una penna a sfera), un pezzettino di tubo di plastica e qualche filo di basso calibro. La Figura 9-30 mostra come si assemblano tutti i componenti.
Figura 9-30 - Un sensore di impatto o di shock fatto in casa.
Se avete bisogno di una maggiore precisione, potete trovare sensori di shock industriali calibrati per livelli di forza specifici. Questi si utilizzano per esempio per testare gli impatti delle automobili o la tolleranza agli impatti dei contenitori per inviare dispositivi delicati. In ogni caso, non sono economici.
I sensori di movimento La capacità di rilevare cambiamenti angolari della posizione a velocità variabili è la
chiave per mantenere stabili le cose nello spazio tridimensionale. Molti quadricotteri (o droni, come a volte vengono chiamati) incorporano qualche forma di rilevamento del movimento su diversi assi per simulare il funzionamento di un vero giroscopio meccanico o IMU (inertial management unit). Questi tipi di dispositivi sono diffusi anche presso gli appassionati di aerei ed elicotteri RC e alcuni utenti avventurosi li hanno inseriti in modellini di razzi per seguire e registrare il movimento del razzo durante il volo. I recenti progressi della tecnologia e delle tecniche di produzione hanno permesso di abbassare i prezzi di questi dispositivi a livelli impossibili da immaginare in passato. Un giroscopio a stato solido o un accelerometro che prima costavano perfino 50 $ adesso possono essere acquistati per circa 10 $. Per via del basso costo e del fatto che i componenti IC sono package molto piccoli a montaggio superficiale a passo stretto, ha più senso acquistare un modulo piuttosto che cercare di assemblare qualcosa partendo da zero, a meno che, naturalmente, non vogliate utilizzarlo come parte di qualcosa di più grande e non abbiate la capacità di utilizzare componenti a montaggio superficiale.
I giroscopi Il termine “giroscopio” è improprio quando lo si applica a dispositivi digitali di rilevamento. A differenza dei giroscopi meccanici veri e propri, questi dispositivi sono più simili a sensori di velocità angolare pensati per rilevare il movimento intorno a un asse. Non fanno riferimento per natura a una posizione di partenza inerziale come un giroscopio vero e proprio. Un IMU può farlo, ma la maggior parte dei dispositivi IMU elettromeccanici sono oggetti grandi e pesanti con tre (o più) giroscopi interni ad alta velocità in cuscinetti a sfera di precisione con motori elettrici e sensori di posizione. Tendono anche a essere molto, molto cari. Tuttavia, con un po’ di programmazione intelligente e l’uso di accelerometri multiassiali (che vedremo tra poco) è possibile simulare un’IMU. La Figura 9-31 mostra un modulo giroscopio da tre assi, venduto da DealeXtreme, Banggood e altri distributori.
Figura 9-31 - Un modulo giroscopio da tre assi.
Gli accelerometri Un accelerometro percepisce un cambiamento di velocità su un determinato asse lineare. Quando l’accelerometro si muove a una velocità costante, non rileva nessun cambiamento, ma quando la velocità cambia per via dell’accelerazione o della decelerazione, il sensore genera un output. Un accelerometro da tre assi rileva i cambiamenti di velocità sugli assi x, y e z. La Figura 9-32 mostra un modulo accelerometro da un solo asse economico, basato su MMA7361 e venduto da DealeXtreme, ma moduli come questo si trovano anche presso Adafruit, SparkFun e altri rivenditori.
Figura 9-32 - Un modulo accelerometro.
I sensori a contatto e di posizione I sensori a contatto si trovano in applicazioni di ogni tipo, dalle macchine per l’imbottigliamento delle bevande agli strumenti controllati dal computer in negozi di macchine. I pulsanti sulle scatole di effetti come quelle che utilizzano i musicisti sono un tipo di sensore a contatto. Ma, a prescindere da come sono fatti, i sensori a contatto funzionano tutti in base allo stesso principio: o sono in contatto fisico con qualcosa, oppure non lo sono. I sensori di posizione, come suggerisce il loro nome, si utilizzano per rilevare la posizione di qualcosa. A differenza dei sensori a contatto, di solito quelli di posizione hanno la capacità di percepire il grado di vicinanza oppure una certa quantità di rotazione angolare. Alcuni sensori di posizione utilizzano la luce riflessa, altri utilizzano il suono e altri ancora incorporano un rotore progettato specificamente e un fascio di luce per misurare il movimento angolare. Un’altra forma di sensore di posizione, detto encoder assoluto, utilizza un disco di vetro interno con dei segni molto sottili per determinare il grado preciso di rotazione di un albero. Gli encoder assoluti non sono trattati qui.
Gli interruttori a contatto Un interruttore a contatto può essere semplice come un filo “whisker” fatto con una bobina con un palo conduttivo nel centro, come quelli che si trovano nei piccoli insetti robot che si vendono nei negozi di giocattoli. Quando il whisker si piega, la bobina entra in contatto con il palo conduttivo e chiude il circuito. In altre parole, non è altro che un interruttore. La Figura 9-33 mostra un’immagine più da vicino di questo tipo di sensore a contatto.
Figura 9-33 - Un sensore a contatto con bobina whisker.
All’altra estremità dello spettro ci sono i cosiddetti interruttori a scatto, come quello montato su un modulo nella Figura 9-34. Questo è un modulo sensore di impatto Meeeno. Questi tipi di interruttori spesso si trovano in applicazioni come sensori di limiti per oggetti di robotica o strumenti per macchine CNC (computer-numeric controlled).
Figura 9-34 - Un tipico interruttore a scatto.
Un pulsante può anche fungere da sensore a contatto. Gli interruttori a pressione di vecchio stile che si utilizzavano sulle automobili per accendere la luce all’interno del veicolo quando la porta era aperta sono eccellenti sensori a contatto (anche se possono richiedere una certa forza per attivarli, più di quella che può fornire un piccolo robot tipico). Per rilevare il contatto fisico si possono utilizzare perfino una striscia di rame e una vite, come mostra la Figura 9-35. L’importante è che l’interruttore chiuda (o apra) il circuito, in modo che un Arduino possa accorgersene e rispondervi.
Figura 9-35 - Un semplice sensore a contatto fatto con una striscia di metallo.
Gli encoder rotativi digitali Un encoder rotativo digitale, come le unità mostrate nella Figura 9-36, genera impulsi oppure emette un valore numerico quando viene ruotato un albero. Anche il modulo KY040 utilizza un encoder rotativo. Alcuni encoder rotativi presentano sull’albero dei denti di arresto in modo che l’operatore possa notare dei lievi urti mentre lo gira. Nel caso di applicazioni che non richiedono che qualcuno giri una manopola, l’albero si muove liberamente e continuamente. Nel Capitolo 12 trovate un esempio di come si crea un software per leggere un encoder rotativo come il KY-040.
Figura 9-36 - Gli encoder rotativi digitali.
I mouse vecchio stile dei computer utilizzavano una sfera di metallo rivestita anziché un LED e due encoder rotativi per rilevare il movimento della sfera. Questi stanno diventando rari, ma al loro interno presentano alcuni componenti interessanti. Se ne smontate uno, notate le ruote di plastica con delle fessure a distanza uniforme. Quando le ruote si muovono, il fascio di luce di un LED viene interrotto. Rilevando il ritmo degli impulsi, il piccolo microcontroller contenuto nel mouse può generare valori numerici che indichino quanto lontano si è spostato il mouse nelle direzioni x e y su una superficie. La Figura 9-37 mostra la parte interna di un tipico mouse a sfera.
Figura 9-37 - Un mouse del vecchio stile con una sfera ed encoder rotativi.
In questo mouse in particolare, il LED sender e il fototransistor (o fotodiodo, forse) sono due componenti separati. Altri modelli di questi vecchi mouse a sfera utilizzano interruttori ottici, come quelli che si utilizzano nel modulo KY-010 mostrato nella Tabella 9-7. Le ruote dell’interruttore sono gestite da alberi in contatto con i lati della sfera di metallo. Se mai avete utilizzato un mouse a sfera per un po’ di tempo, sapere che occasionalmente dovete rimuovere la sfera e pulire tutto lo sporco che si è accumulato sull’albero (e anche sulla sfera). Le ruote dell’interruttore e i sensori ottici possono essere rimossi e riutilizzati in qualcos’altro (francamente, le ruote dell’interruttore sono probabilmente la parte più utile di un mouse di questo tipo).
I trasmettitori/ricevitori laser Il modulo mostrato nella Figura 9-38 è un trasmettitore e ricevitore laser a corto raggio progettato principalmente per rilevare ostacoli o svolgere qualsiasi altra operazione dove si possa utilizzare la riflettanza per rilevare un oggetto. Può essere utilizzato come collegamento di dati, ma le ottiche dovrebbero essere perfezionate per raggiungere un raggio significativo.
Figura 9-38 - Il rilevatore di oggetti laser a corto raggio.
I sensori di distanza La capacità sia di rilevare un oggetto che di determinarne la distanza dal sensore è una funzione chiave in molte applicazioni di robotica. Un sensore di distanza di solito utilizza la riflessione, che sia della luce, del suono o di onde radio nel caso di un radar. Qui vedremo il suono e la luce, dal momento che i sensori radar tendono a essere piuttosto costosi e funzionano meglio sulle grandi distanze. Per rilevare un corto raggio, vanno bene sensori ottici o acustici, che sono molto economici.
I sensori di oggetti con LED Un sensore di oggetti con LED funziona misurando la luce emessa da un LED (che sia ottica o IR) e riflessa da una superficie. Questi dispositivi di solito hanno un LED IR e un rilevatore situati uno a fianco all’altro, come nel modulo mostrato nella Figura 9-39. Non misurano il tempo che impiega la luce a viaggiare dall’emettitore e tornare al sensore, perché a corto raggio la velocità della luce lo renderebbe estremamente difficile da calcolare. Se volete misurare la distanza dalla Terra alla Luna utilizzando uno dei retroriflettori lasciati dalle missioni Apollo, dovete utilizzare un laser a impulsi, un grande telescopio e un buon timer ad alta precisione: Nel caso di Arduino, invece, un sensore riflettente basterà per evitare a un piccolo robot di andare a sbattere contro il muro o per permettergli di seguire una linea sul pavimento.
Figura 9-39 - Il modulo sensore di oggetti riflettente.
I misuratori di distanza a ultrasuoni Se siete abbastanza grandi, potete ricordare le vecchie fotocamere “istantanee” che includevano un misuratore di distanza a ultrasuoni per mettere a fuoco automaticamente il soggetto e scattare una fotografia che potevate guardare mentre si sviluppava. Il misuratore di distanza di solito consisteva di un paio di sensori piezoelettrici, uno collegato come emettitore e l’altro come ricevitore. L’emettitore generava un breve impulso di ultrasuoni e l’eco veniva rilevato dal ricevitore. Con questo tipo di misuratore di distanza, il tempo tra l’output dell’impulso e il ritorno dell’eco è determinato dalla distanza di quello che stanno puntando i sensori. Questo funziona perché il suono si muove con relativa lentezza e quindi ottenere il tempo trascorso tra l’impulso e il ritorno non è una cosa particolarmente difficile da fare con una logica abbastanza veloce. Oggigiorno, potete trovare un misuratore di distanza a ultrasuoni per pochi euro e lo potete collegare a una scheda Arduino. Un esempio di un sensore a ultrasuoni facile da trovare è il modulo 20-019-100 mostrato nella Tabella 9-8.
Le comunicazioni Esistono numerosi moduli per applicazioni basate sulle comunicazioni, da semplici adattatori RS-232 a moduli trasmettitori/ricevitori di comunicazioni wireless e laser.
I moduli wireless APC220 I moduli ricetrasmittente APC220 funzionano tra i 418 e i 455 MHz. Un collegamento digitale completo consiste di due moduli e un adattatore USB opzionale. Questo permette a un modulo di collegarsi a un PC e all’altro di collegarsi a una scheda Arduino. L’APC220 è in grado di trasferire dati a 19.200 bit al secondo, con un raggio di
fino 1.000 metri. La shield multifunzione descritta in “Shield varie” a pagina 273 include un punto di connessione per un modulo APC220, così come la shield LCD 16 × 2 di DFRobot (anch’essa analizzata nel Capitolo 8). La Figura 9-40 mostra un paio di moduli APC220.
Figura 9-40 - I moduli ricetrasmittente RF APC220 (immagine: DFRobot).
I moduli RF 315/433 MHz Questi moduli, con un raggio di fino a 500 piedi (150 metri), sono alternative a basso costo dell’APC220. Lo svantaggio è che non sono ricetrasmittenti, ma si presentano come una coppia di trasmettitore e ricevitore, come mostra la Figura 9-41. Sono disponibili preimpostati su 315 MHz o 433 MHz. Notate che dovete aggiungervi la vostra propria antenna.
Figura 9-41 - Il trasmettitore e ricevitore a 433 MHz.
La ricetrasmittente ESP8266 Questo modulo WiFi altamente integrato, mostrato nella Figura 9-42, supporta i protocolli 802.11 b/g/n e utilizza un’interfaccia seriale per comunicare con un Arduino. La MCU da 32 bit integrata nella scheda ha uno stack di protocolli di rete TCP/IP nel suo firmware. Gestisce i dettagli di basso livello per stabilire e mantenere un collegamento digitale e quindi l’unica cosa che deve fare Arduino è specificare un indirizzo con il quale collegarsi, oppure aspettare che qualche altro modulo si colleghi con lui.
Figura 9-42 - Un modulo ricetrasmittente WiFi.
L’NRF24L01 Il modulo NRF24L01, mostrato nella Figura 9-43, è una ricetrasmittente a basso consumo che lavora a 2,4 GHz con un raggio di circa 800 piedi (250 metri). Per comunicare con Arduino utilizza un’interfaccia SPI. Questi moduli possono essere acquistati per circa 3 $ da diversi rivenditori.
Figura 9-43 - La ricetrasmittente RF NRF24L01.
L’adattatore RS-232 I dispositivi MCU AVR che si utilizzano sulle schede Arduino hanno un UART (o USART, se preferite adottare la terminologia di Atmel) integrato, ma che non genera segnali RS232 standard. Anziché costruire un convertitore personalizzato, il modulo adattatore RS232 fornisce il convertitore, l’ID e un connettore DB-9, come mostra la Figura 9-44. I pin RxD e TxD della MCU si collegano direttamente al modulo.
Figura 9-44 - Il modulo adattatore RS-232.
Dispositivi e componenti di output Un output proveniente da una scheda Arduino può essere un LED, un servo motore, un relè, oppure qualche altro modulo, componente o dispositivo che risponda a un segnale o a un comando che venga dal microcontroller AVR di Arduino. Questo paragrafo comincia con le fonti di luce, seguite dai relè, dai motori e dai servo. Parla anche delle fonti di suono, come l’altoparlante KY-006 che risponde agli impulsi e che appare nella Tabella 9-7. I componenti relativi all’input e all’output dell’utente sono trattati in paragrafi successivi.
Le fonti di luce Le fonti di luce possono essere lampadine vecchio stile in una vasta gamma di tipi e dimensioni, oppure LED, dispositivi a stato solido che si comportano come diodi ma emettono un bagliore intenso quando li attraversa la corrente. In questo paragrafo ci concentreremo sui LED, principalmente perché sono economici, durano a lungo e non sempre hanno bisogno di un circuito per gestirli. Perfino una piccola lampadina a incandescenza può consumare una quantità significativa di corrente e tendere a surriscaldarsi o a bruciarsi. Detto questo, non c’è ragione per cui non possiate utilizzare lampadine a incandescenza: dovete soltanto prepararvi ad affrontare la complessità (e il costo) di un ulteriore circuito e la necessità di sostituire occasionalmente una lampadina bruciata. I LED sono disponibili in una vasta gamma di stili, dimensioni e colori. Un microcontroller AVR può fornire dai 5 ai 10 mA necessari per gestire un LED, ma generalmente non è una buona idea collegare direttamente diversi LED oppure cercare di gestire qualcosa come un modulo LED ad alto output. Per questo, il modo migliore di procedere è con un driver di qualche tipo. Le prossime immagini mostrano alcuni dei tipi di LED disponibili e che si possono anche trovare già montati sulle PCB dei moduli, come quelli mostrati nella Tabella 9-7 e nella Tabella 9-9.
I LED a un solo colore I LED a un solo colore possono avere dimensioni che vanno da minuscoli componenti a montaggio superficiale, come il LED D13 della scheda Arduino, agli enormi dispositivi utilizzati per applicazioni di illuminazione. La Figura 9-45 mostra una selezione di alcuni dei vari tipi disponibili.
Figura 9-45 - Un comune LED di un solo colore.
I LED bicolori Un LED bicolore è fondamentalmente una coppia di LED montati in un unico package, che generalmente si presenta come un LED normale con una connessione interna come quella mostrata nella Figura 9-46. I LED interni sono collegati al contrario l’uno rispetto all’altro. Quando la corrente fluisce in una direzione, uno dei LED si accende e quando la corrente viene invertita si accende l’altro.
Figura 9-46 - Le connessioni interne di un LED bicolore con due terminali.
Un altro tipo disponibile di LED bicolori utilizza tre terminali. Uno è comune e gli altri due si collegano ciascuno a uno dei chip del LED all’interno del package di plastica del dispositivo.
I LED tricolori (RGB) Un LED tricolore è composto da tre chip separati in un unico package di plastica. La Figura 9-47 mostra un componente a montaggio superficiale. È possibile montarne un gran numero in una serie su un’unica PCB e diverse PCB possono essere montate una a fianco all’altra per creare un grande display LED pieno di colori.
Figura 9-47 - Un LED tricolore a montaggio superficiale.
Un LED tricolore può produrre un’approssimazione di qualsiasi colore visibile variando l’intensità`dell’output di ciascuno dei LED interni. Dal momento che le matrici dei LED (i chip dei singoli LED) sono fisicamente separate, i colori si miscelano con un diffusore di un qualche tipo. Dalla distanza può sembrare convincente. LED RGB ad alta potenza e alto output sono stati utilizzati per creare enormi display a colori, come quelli che si vedono accanto agli edifici o nei grandi stadi sportivi.
Le matrici di LED Una matrice di LED è utile per una vasta gamma di applicazioni. Una matrice 8 × 8, come quella mostrata nella Figura 9-48, può essere utilizzata per mostrare lettere o numeri. Se disponete diversi di questi moduli uno accanto all’altro, potete creare un display con il testo che scorre.
Figura 9-48 - Una matrice di LED 8 × 8.
Notate che il modulo è progettato in modo che rimanga soltanto pochissimo spazio tra i LED e i bordi del modulo. Quando questi tipi di moduli matrice sono montati uno accanto all’altro, la distanza tra l’ultima colonna o l’ultima riga su un modulo e la colonna o la riga adiacente sul modulo successivo è uguale alla distanza tra i LED che si trovano al centro del modulo. Questo mantiene uniforme la distanza quando si utilizzano molti moduli per creare display grandi.
I display LED a 7 segmenti Il venerabile display a 7 segmenti esiste da molto tempo. Oltre a singoli LED, questa è stata la prima applicazione valida per la tecnologia a LED e prima della fine degli anni ’70 i moduli display con cifre LED a 7 segmenti e alfanumerici cominciavano ad apparire in applicazioni di ogni tipo. La Figura 9-49 mostra un tipico modulo display da 4 cifre.
Figura 9-49 - Un tipico display a 7 segmenti a 4 cifre.
Come nel caso del modulo matrice di LED mostrato nella Figura 9-48, la distanza sui bordi di questo modulo è inferiore, in modo che si possano montare diversi moduli uno accanto all’altro. Con tre di questi componenti potete facilmente creare un display a virgola mobile da 12 cifre.
I moduli LED a 7 segmenti I moduli display a 7 segmenti sono disponibili con interfaccia I2C o SPI integrata. Il modulo mostrato nella Figura 9-50 ne è un esempio. Questo specifico modulo può essere acquistato presso Tindie (vedere Tabella 9-11). Esistono anche moduli con diversi display e si trovano in rosso, verde, giallo e blu.
Figura 9-50 - Un modulo display a 7 segmenti con interfaccia SPI.
I laser Alcuni tipi di fonti di luce con diodo sono anche i laser come quelli che si trovano nei puntatori laser, mentre altri sono abbastanza potenti da tagliare la plastica o il legno. Un laser a stato solido è essenzialmente un LED con alcune modifiche interne per fargli produrre una luce coerente. I LED laser sono disponibili con lunghezze d’onda di output che vanno da infrarosso a blu. Senza questi dispositivi, cose come livelli laser per lavori di costruzione, puntatori per docenti e istruttori, profilatori di superfici per la modellazione 3D, riproduttori e registratori CD e DVD e alcuni tipi di strumenti da taglio industriali non sarebbero possibili. Un tipico piccolo modulo LED laser è mostrato nella Figura 9-51 (si tratta di un KY-008).
Figura 9-51 - Un tipico LED laser rosso a bassa potenza.
Il LED laser può essere acquistato come componente separato presso distributori di elettronica.
I relè, i motori e i servo Molti piccoli relè possono trasportare più corrente per alimentare la bobina interna rispetto a quanto non possa fare con sicurezza il microcontroller AVR della PCB di Arduino. I motori e i servo sono esempi di dispositivi molto utili che spesso hanno bisogno di un componente driver di qualche tipo che fornisca loro la corrente di cui hanno bisogno per funzionare.
I relè I relè esistono in una vasta gamma di dimensioni e forme, da piccoli package che sembrano IC DIP da 14 pin a oggetti enormi per controllare grandi carichi in attrezzature industriali. Nel caso della maggior parte delle applicazioni Arduino, è sufficiente un piccolo relè. Un piccolo relè può gestire un relè più grande, che a sua volta può gestirne uno ancora più grande e così via. Il KY-019 è un esempio di un modulo relè che può essere collegato direttamente ad Arduino. Il driver di un relè può essere un semplice transistor 2N2222, oppure può trattarsi di un IC progettato specificamente per gestire la corrente e i picchi inversi incontrati con i relè. Il circuito mostrato nella Figura 9-5, che abbiamo visto prima, utilizza un transistor NPN per controllare un piccolo relè montato sulla PCB. La Figura 9-52 mostra un modulo con quattro relè. La PCB include anche i transistor del driver, le resistenze e i diodi necessari. Tutto quello che è richiesto è una sorgente di DC 5 V per gestire le bobine dei relè e segnali logici standard per controllarli.
Figura 9-52 - Un modulo relè con quattro relè montati sulla PCB.
Il controllo dei servo Il termine servo di solito si riferisce a piccoli dispositivi simili a motori, anche se in passato veniva utilizzato per riferirsi a ingombranti attuatori utilizzati per cose come come il posizionamento di pistole su una nave militare o l’esecuzione di calcoli analogici. I tipici piccoli servo, come quelli mostrati nella Figura 9-53, si utilizzano nelle macchinine e negli aereini radiocontrollati, oltre che nella robotica a livello di hobby.
Figura 9-53 - Una selezione di piccoli servo.
Anche se esistono delle shield da usare con i servo (vedere Capitolo 8), un microcontroller AVR può gestire questi dispositivi direttamente con i suoi output PWM. Un servo come quelli mostrati nella Figura 9-53 ruota un albero di 180 gradi, con la quantità della rotazione determinata dall’ampiezza dell’impulso e dalla frequenza di un segnale di controllo.
Il controllo di motori DC I motori DC di solito sono controllati con quello che viene detto circuito “a ponte H” e la Figura 9-54 mostra un diagramma semplificato.
Figura 9-54 - Un ponte H semplificato.
Un ponte H può essere utilizzato con DC continua o con un segnale PWM e, a seconda di come è gestito il motore, può girare in un senso o nell’altro. Non vi consiglio di costruire un circuito di controllo di un motore a partire da zero (a meno che non vogliate davvero farlo, naturalmente). Una shield come quella mostrata nella Figura 9-55 è dotata di tutto il necessario per controllare un motore DC. Ha anche un radiatore per dissipare il calore generato con grandi carichi di corrente. Questa particolare shield è di Seeed Studio (http://bit.ly/seeed-motor-v2). Notate che la shield controlla due motori DC oppure un motore passo-passo.
Figura 9-55 - Una shield per controllare motori.
Il controllo di motori passo-passo I motori passo-passo sono relativamente semplici da controllare, una volta che si forniscono loro i necessari componenti elettronici per generare gli impulsi che facciano girare l’albero. Un requisito è la corrente e, anche se un IC come l’ULN2003A fornisce tutto il necessario per gestire un piccolo motore passo-passo, non riesce a gestire motori grandi che richiedono molta corrente. L’ULN2003A è fondamentalmente soltanto una serie di otto transistor Darlington e quindi Arduino deve occuparsi di tutto il timing per gli impulsi del motore. Esistono delle shield (vedere Capitolo 8) che contengono i circuiti per fino a quattro motori passo-passo, insieme ai connettori necessari per collegarli in un modo leggermente più facile. Come nel caso dei motori DC, utilizzare qualcosa che è già costruito è molto più facile che costruire qualcosa a partire da zero e, se considerate anche il tempo necessario, probabilmente risulta anche più economico.
Gli output dei segnali analogici
I segnali analogici sono i fenomeni ciclici continuamente variabili che spesso definiamo suono, oltre a quei segnali oltre l’intervallo udibile per gli esseri umani, come quelli radio. Esistono diversi modi di utilizzare una scheda Arduino per produrre segnali analogici di tipo onda sinusoidale, dei quali tutti richiedono qualche componente esterno aggiuntivo. Un microcontroller AVR non incorpora un convertitore digitale-analogico (DAC) nel suo design, per cui, se volete ottenere qualcosa di diverso da onde quadre da un output PWM o del timer, avete bisogno di qualcosa per generare i segnali.
I cicalini I cicalini possono essere oggetti semplici che emettono un tono ad altezza fissa quando sono attivi, oppure possono essere leggermente più sofisticati e generare un picco programmabile. Il KY-006 e il KY-012 sono esempi di questi tipi di sorgenti audio.
I moduli DAC Un modo di fornire ad Arduino la funzionalità digitale-analogico è con un modulo DAC, come l’unità mostrata nella Figura 9-56. Questo prodotto in particolare è di Adafruit e si basa sull’IC MCP4725, che è un DAC a un solo canale da 12 bit con un’interfaccia I2C.
Figura 9-56 - Il modulo DAC basato su MCP4725.
Un DAC si rivela utile quando c’è bisogno di un segnale continuamente variabile, come una tensione di controllo per qualche altro circuito o dispositivo. Un DAC può essere utilizzato anche per generare una forma d’onda come una rampa o un’onda sinusoidale. Con la velocità delle comunicazioni da 100 Kb/s della modalità standard I2C utilizzata con i microcontroller AVR non è possibile raggiungere la velocità di aggiornamento possibile con tipi di interfaccia I2C più rapidi, ma un DAC può comunque generare una rispettabile onda sinusoidale a bassa frequenza. Lo svantaggio è che l’AVR di solito non sta facendo nient’altro che aggiornare il DAC per produrre forme d’onda.
I generatori di forme d’onda Anche se è possibile generare forme d’onda a bassa frequenza direttamente con una scheda Arduino e un modulo DAC, per forme d’onda di qualità oltre a circa 1 kHz è necessario un altro circuito. Un dispositivo di questo tipo è il modulo DDS (direct digital synthesis) mostrato nella Figura 9-57.
Figura 9-57 - Il modulo DDS basato sull’AD9850.
L’IC AD9850 può generare sia onde quadre che onde sinusoidali da 1 Hz a 40 MHz. Potete scaricare la scheda tecnica dell’AD9850 da Analog Devices (http://bit.ly/ad9850data). L’AD9850 utilizza la sua propria interfaccia unica e può essere controllata utilizzando un’interfaccia parallela da 8 bit o una seriale. Esistono anche le librerie di Arduino per il AD9850.
L’input dell’utente A volte è necessario che un umano interagisca direttamente con un progetto di Arduino e questo significa utilizzare pulsanti, manopole, tastierini e joystick. Oltre ai moduli descritti in questo capitolo, potete acquistare anche i componenti singoli e montarli come preferite.
I tastierini Il termine “tastierino” di solito si riferisce a una serie di interruttori uno accanto all’altro con etichette, di solito disposti in una griglia di 3 × 3, 3 × 4 o 4 × 4. Può riferirsi anche a un cosiddetto tastierino a membrana, che è una serie di piccoli interruttori a membrana su una PCB. Di solito i tasti sono contrassegnati con lettere e numeri, come gli esempi mostrati nella Figura 9-58. I tastierini non devono per forza essere rettangolari, ma se ne trovano in una vasta gamma di stili e layout. In effetti, la tastiera di un computer non
è altro che un tastierino molto grande.
Figura 9-58 - Un assortimento di tastierini.
I joystick I joystick di solito possono essere di due tipi: analogici continui oppure digitali discreti. Un joystick analogico continuo, come quello mostrato nella Figura 9-59, utilizza due potenziometri, ciascun collegato agli assi x e y. I valori letti dai potenziometri indicano quanto lontano si è spostato il joystick e in quale posizione si trova attualmente.
Figura 9-59 - Un modulo joystick analogico.
Un joystick digitale discreto utilizza piccoli interruttori o altri tipi di rilevatori per rilevare quando è stato spostato il joystick alla sua estensione massima in entrambe le direzioni, x o y. Questi tipi di joystick venivano utilizzati con i primi giochi economici di fascia consumer e i personal computer. Sono dispositivi “tutto o niente”, ma sono economici da produrre e non presentano problemi con lo sporco e l’usura che possono affliggere i joystick analogici. Molte shield LCD incorporano un joystick discreto.
I potenziometri e gli encoder rotativi Un potenziometro è una resistenza variabile, di solito utilizzata per il controllo dell’input. Un potenziometro può essere utilizzato in un modulo dimmer per le luci, come controllo del volume, come controllo dell’input per uno strumento di test, oppure come input per una vasta gamma di circuiti analogici. I moduli TinkerKit T000140 e T000150 sono esempi di potenziometri. Un encoder rotativo, come quello mostrato prima nella Figura 9-36, può anche essere utilizzato come dispositivo di input dell’utente. Anziché produrre una tensione variabile che deve essere convertita in numeri digitali per poter essere utilizzata da un microcontroller AVR, l’encoder rotativo produce output digitale che può essere utilizzato direttamente.
L’output dell’utente
La capacità di mostrare informazioni a un utente vi permette di rendere il vostro progetto veramente interattivo. Può trattarsi di un semplice stato rivelato da LED, oppure di messaggi complessi o di immagini su uno display LCD o TFT. Qualunque forma prendano, i dispositivi di output offrono all’utente un feedback immediato in risposta agli input dei comandi. Esiste una vasta gamma di display che possono essere utilizzati con Arduino. Le shield display LCD descritte nel Capitolo 8 utilizzano gli stessi componenti, ma in una forma più comoda. Ci sono, comunque situazioni nelle quali una shield può non risultare appropriata e in questi casi un componente display LCD che può essere montato in una certa maniera può rivelarsi una scelta migliore. NOTA Altri esempi di display nella forma di shield per le schede Arduino sono descritti nel Capitolo 8. Assicuratevi di leggerlo. A meno che non abbiate l’assoluta necessità di utilizzare un display con i pin nudi, una shield è una soluzione molto più facile.
I display di testo Alcuni dei display solo testo più comuni ed economici hanno da 1 a 4 righe, con ciascuna riga capace di mostrare 8, 16, 20, 24, 32 o 40 caratteri. Naturalmente, man mano che aumenta la densità del display, lo fa anche il prezzo. Un display da 1 riga e 8 caratteri può costare circa 2 $, mentre un display da 4 righe e 40 caratteri può aggirarsi intorno ai 18 $.
L’ERM1601SBS-2 Il display LCD ERM1601SBS-2 è un display LCD 16 × 1 con caratteri bianchi su sfondo blu. Nella Figura 9-60 è mostrato un modulo tipico. Questi display utilizzano un chip controller HD44780 o KS066 e retroilluminazione LED e questa unità in particolare costa intorno ai 3 $. Trovate prodotti simili con lettere nere su sfondo giallo-verde e lettere nere su sfondo bianco.
Figura 9-60 - Il modulo display ERM1601SBS-2.
L’ST7066 (HD44780) Questo è un display LCD 16 × 2 con una semplice interfaccia parallela che utilizza un controller ST7066 o HD44780. Si tratta dello stesso componente che si trova sulle shield display LCD di Adafruit, SparkFun, SainSmart e altri rivenditori. La Figura 9-61 mostra un esempio di questo tipo di display. Costa circa 10 $.
Figura 9-61 - Un display 16 × 2 che utilizza un controller HD44780 o ST7066.
Potete notare che l’ERM1601SBS-2 mostrato nella Figura 9-60 assomiglia molto al display mostrato nella Figura 9-61. Questo perché entrambi utilizzano gli stessi IC per gestire l’LCD. L’unica grande differenza è che uno ha un display da una sola riga e l’altro un display da due righe. Altri tipi di display LCD sia non grafici che grafici si trovano presso vari rivenditori. Occasionalmente, potete trovare avanzi di magazzino a prezzi molto bassi e, se utilizzano un chip controller standard, di solito possono essere integrati facilmente in un
progetto di Arduino. Lo svantaggio è che spesso questi display avanzati hanno simboli speciali integrati e quindi potete ritrovarsi con un display molto economico ma con i simboli di un forno a microonde o di un sistema di irrigazione del giardino che non vi servono (o magari sì…).
I display grafici I display grafici sono disponibili utilizzando tecnologie LCD, TFT o OLED in formati sia monocromatici che a colori. I dispositivi TFT e OLED hanno un aspetto decisamente migliore rispetto ai semplici LCD a matrice di punti, ma la bellezza ha un prezzo.
L’ERC240128SBS-1 Il display ERC240128SBS-1, mostrato nella Figura 9-62, è un display LCD a matrice di punti 240 × 128 con un’interfaccia parallela da 8 bit. Si trova presso BuyDisplay (http://www.buydisplay.com).
Figura 9-62 - Un display TFT a colori 240 × 128.
L’ST7735R Un esempio di un altro tipo di display è l’unità TFT 128 × 160 TFT venduta da Adafruit e mostrata nella Figura 9-63. Questo display ha una dimensione diagonale di 1,8 pollici (4,6 cm) e supporta una selezione di colori a 18 bit per un totale di 262.144 tonalità diverse. Utilizza un controller ST7735R con un’interfaccia SPI e include perfino un lettore di schede microSD sulla parte posteriore della PCB.
Figura 9-63 - Un modulo display TFT a colori da 1,8”.
Funzioni di supporto La maggior parte dei moduli forniscono funzioni di input o di output. Non molti hanno funzioni che possono essere classificate come di supporto non-I/O. Quelli che lo fanno generalmente ricadono nelle categorie di clock e timer.
I clock Esistono diversi tipi di IC RTC (real-time clock), come il DS1302, il DS1307, il DS3231 e il PCF8563. Tutti fanno fondamentalmente la stessa cosa: tengono traccia dell’ora e della data. Alcuni hanno una EEPROM integrata e altri no. Alcuni utilizzano un’interfaccia non standard, alcuni utilizzano SPI e altri utilizzano I2C. A parte le evidenti differenze di interfaccia, le differenze principali riguardano ampiamente la precisione come funzione di stabilità nel corso del tempo, di sensibilità alla temperatura, di consumo energetico e di costo. Quattro moduli RTC che si trovano spesso sono quelli basati sugli IC DS1302, DS1307, DS3231 e PCF8563. I moduli di solito sono dotati di un supporto per una batteria a bottone, spesso una CR2032 o una LIR2032. Test indipendenti hanno mostrato che la DS3231 offre la maggiore stabilità generale a lungo termine, ma gli altri RTC si possono utilizzare perfettamente. I moduli con cristalli esterni possono soffrire di deriva termica indotta e tutti deviano di qualche grado nel corso di lunghi periodi di tempo.
Il modulo RTC DS1302 L’IC RTC DS1302 (Figura 9-64) utilizza un’interfaccia seriale non standard. Non è SPI, ma è clocked. Una linea trasporta i dati, una è il segnale del clock e un’altra è la linea CE (chip enable). Questa è quella che Maxim (prima Dallas Semiconductor) definisce
un’interfaccia a tre fili. La Figura 9-64 mostra un tipico modulo DS1302. Trovate maggiori informazioni sul DS1302 su Maxim Integrated (http://bit.ly/maxim-ds1307).
Figura 9-64 - Un modulo RTC DS1302.
Il modulo RTC DS1307 L’RTC DS1307 è un dispositivo I2C. Non è compatibile né dal punto di vista del codice né dei pin con il DS1302, ma il risultato finale è lo stesso. Trovate maggiori dettagli sulle schede tecniche di Maxim (http://bit.ly/maxim-ds1307). La Figura 9-65 mostra un modulo RTC DS1307 di Tronixlabs (http://tronixlabs.com).
Figura 9-65 - Un modulo RTC DS1307.
Il modulo RTC DS3231 Come il DS1307, l’RTC DS3231 utilizza un’interfaccia I2C e dal punto di vista del codice è compatibile con il DS1307. La differenza principale è la precisione. Il DS3231 utilizza un cristallo interno e questo lo rende meno sensibile alla temperatura. La Figura 9-66 mostra un tipico modulo RTC DS3231.
Figura 9-66 - Un modulo RTC DS3231.
Il modulo RTC che utilizza PCF8563 Il PCF8563 è un altro IC RTC con un’interfaccia I2C. È un componente NXP (http://www.nxp.com) e i suoi registri interni sono completamente diversi da quelli del DS1307 o del DS3231 di Maxim. La Figura 9-67 mostra un tipico modulo basato sul PCF8563.
Figura 9-67 - Un modulo RTC PCF8563.
I timer Anche se la MCU AVR contiene un timer watchdog integrato, esistono moduli che svolgono essenzialmente la stessa funzione. Una possibile applicazione per un watchdog esterno (per essere più precisi, un timer a conto alla rovescia resettabile), è quando ha senso che il segnale di reset del timer provenga da un dispositivo esterno anziché dall’AVR stesso. Prendete per esempio un meccanismo rotativo con un sensore magnetico che emette un impulso per ciascuna rivoluzione dell’albero. Se gli impulsi vengono utilizzati per resettare un timer watchdog esterno, questo può rilevare quando il meccanismo si guasta e smette di girare. Utilizzando un interrupt o semplicemente monitorando lo stato del timer per il conto alla rovescia, la MCU può rilevare la condizione di guasto e agire di conseguenza. Molti moduli timer esterni utilizzano un timer 555. Un MOSFET si utilizza per scaricare il condensatore di temporizzazione e resettare il timer ogni volta che viene applicato un impulso di reset. Alcuni altri moduli timer di rivenditori asiatici utilizzano una goccia nera di resina epossidica per nascondere quello che sta facendo il timing sulla PCB. Io lo
eviterei, dal momento che non esiste un modo facile di sapere che cosa c’è dentro senza distruggere l’IC sotto la goccia. Se siete interessati ai moduli timer esterni per il conto alla rovescia, vi suggerisco di procurarvi una copia del libro di Howard Berlin The 555 Timer Applications Sourcebook (vedere Appendice D). L’edizione originale del 1979 è fuori stampa, ma potete ancora trovarne delle copie su Amazon e ne esiste una versione più recente, ma leggermente diversa. La società australiana Freetronics (http://www.freetronics.com.au) vende un economico modulo timer watchdog basato su un time 555.
Le connessioni Nel corso degli ultimi anni, nei metodi di interconnessione di moduli e shield ha cominciato a emergere una tendenza, dove i connettori modulari stanno sostituendo i pin e le prese che prima si trovavano sia su shield che su moduli. Detti spesso sistemi, questi implicano una serie di moduli e qualche forma di shield di interfaccia che utilizzino tutti gli stessi tipi di connettori e gli stessi pinout per tensione, segnale e messa a terra. I moduli TinkerKit (elencati nella Tabella 9-9) sono soltanto un esempio di un sistema di connessione dei moduli. Un altro è la linea di moduli Grove e le shield di interfaccia associate di Seeed Studio. Altre shield sono dotate di connettori da tre e quattro pin da utilizzare con cavi già pronti con i relativi connettori su ciascuna estremità, come il kit della patch shield passiva mostrato nella Figura 8-21.
Lavorare con jumper nudi Immaginate di prevedere di collegare in modo permanente un unico modulo a una scheda Arduino (magari per integrarla da qualche parta e lasciare che faccia il suo lavoro per molto tempo) e di non voler dedicare il tempo necessario per costruirvi un connettore. Va benissimo: non c’è niente di male nell’utilizzare jumper, purché eseguiate alcuni semplici passaggi per rendere le connessioni fisicamente più affidabili. I terminali socket (o pin) a crimpare che si utilizzano nei jumper sono gli stessi terminali che si utilizzano nei connettori modulari. La differenza è che un ponticello ha soltanto un terminale, mentre un connettore ne ha due o più. Più terminali da crimpare ci sono in un connettore, più robusto sarà. Questo è dovuto all’attrito meccanico aumentato da diversi terminali che lavorano tutti insieme nello stesso connettore. Un unico ponticello può spostarsi e flettersi e non offrire la stessa presa meccanica che si ottiene con diversi terminali in un solo connettore. Un modo per ottenere una connessione più affidabile è applicare una goccia di gomma di silicone (nota anche con il nome della marca “RTV”) per fissare i connettori dei jumper sui pin del modulo. Può non rivelarsi una soluzione elegante o robusta come un connettore modulare, ma, a meno che il modulo non stia lavorando in un ambiente ad alte vibrazioni con un veicolo RC o uno strumento in una fabbrica, resisterà bene.
Però non esagerate con il silicone, perché magari in qualche momento vorrete togliere e sostituire il modulo. La lama affilata di un rasoio può tagliare la gomma di silicone, che è morbida, e non danneggiare il jumper (se prestate attenzione, naturalmente).
I sistemi di connessione dei moduli In generale, una shield con connettori (che siano dello stile aperto utilizzato da TinkerKit o del tipo chiuso utilizzato dai componenti Grove e altri) può essere utilizzata anche può essere utilizzata o con jumper singoli oppure con socket-header crimpati, proprio, proprio come le shield e i moduli con pin nudi. I connettori già pronti rendono più facile collegare un modulo e non doversi preoccupare di come sono collegati i pin, purché il modulo sia progettato per collegarsi a una determinata shield con gli stessi tipi di connettori. Questo è l’approccio che hanno adottato i moduli TinkerKit e Grove (maggiori informazioni sui moduli Grove possono essere trovate sul sito web di Seeed Studio [http://www.seeedstudio.com]). Altri sistemi, come i moduli TinyDuino di TinyCircuits, utilizzano piccoli connettori multipin a montaggio superficiale. La Figura 9-68 mostra alcuni esempi di questi tipi di moduli. Anche se tecnicamente non si tratta di moduli come quelli descritti in questo capitolo, questo approccio mostra soltanto uno dei molti modi di risolvere il problema dell’interconnessione. TinyCircuits produce anche moduli sensore con lo stesso tipo di connettore e hanno cavi d’estensione disponibili. Queste cose sono molto piccole (guardate il connettore USB su una scheda Nano e poi confrontatela con la Figura 9-68) e la prima cosa che mi è saltata in mente quando le ho viste è stata “modellino di razzo”. Trovate maggiori informazioni sul sito web di TinyCircuits (https://www.tinycircuits.com).
Figura 9-68 - Esempi di moduli proposti da TinyCircuits.
I connettori sono il problema quando si utilizzano moduli e shield fatti per un determinato sistema di interconnessione. Non esiste un unico standard tra tutte le diverse marche e non c’è nessuna garanzia che un modulo fornito da un rivenditore si inserisca in una shield di interfaccia prodotta da qualcun altro. Un modo per risolvere questo è creare
sia la shield di interfaccia che una selezione di moduli con cui lavorare, che è esattamente quello che hanno deciso di fare i ragazzi che stanno dietro ai prodotti TinkerKit. Quando prendere in considerazione un determinato modulo, prestate attenzione al metodo di connessione che utilizza. Dovete anche prepararvi ad acquistare ulteriori cavi e forse alcuni moduli di prototipazione, per interfacciavi con componenti non fatti per un particolare sistema di connessione. Oppure potete scegliere di costruire i vostri cavi personalizzati, come vedremo nel prossimo paragrafo.
Costruire connettori personalizzati I connettori non soltanto sono più facili da utilizzare, ma sono anche più robusti e affidabili dei jumper. Ma non disporre di connettori non è necessariamente un male. Una shield di interfaccia come quella di SainSmart mostrata nella Figura 8-3 ha i pin I/O organizzati in file ordinate, con una distanza di 0,1 pollici (2,54 mm). Un connettore, come quelli mostrati nella Figura 9-69, con la stessa distanza e fori per crimpare i terminali corrisponderà con i pin e creerà una connessione solida.
Figura 9-69 - Pin e socket per terminali crimpati.
Le shell dei connettori e i terminali da crimpare esistono in una vasta gamma di stili. Le shell, o alloggiamenti, sono di disponibili con posizioni per uno o più terminali. Occasionalmente, potete incontrare un ponticello con alloggiamenti di plastica da una sola posizione su ciascuna estremità, anziché l’isolamento termoretraibile che si utilizza anch’esso. Io preferisco le shell di plastica, anche se i jumper sono leggermente più cari. Per coloro che vogliono semplicemente collegare uno o due moduli e non vogliono preoccuparsi del fatto che i jumper si allentino e si scolleghino, l’approccio socket header è un’alternativa che vale la pena considerare. Lo svantaggio è che si deve investire in una crimpatrice e in un paio di buone spellafili. La Figura 9-70 mostra una
crimpatrice e la Figura 9-71 mostra come funziona.
Figura 9-70 - Tipica crimpatrice di terminali.
Figura 9-71 - Come si collega a un filo un terminale crimpato.
La Figura 9-72 mostra una presa da tre posizioni collegata a un modulo sensore di temperatura e umidità (un KY-015 di KEYES).
Figura 9-72 - Utilizzare un header da tre posizioni per collegare un modulo sensore.
Questa organizzazione permette al sensore di essere montato dove è necessario e collegato a una shield di interfaccia. Per assicurarsi che non si stacchi facilmente dal modulo, si può aggiungere una piccola quantità di silicone trasparente tra l’alloggiamento del connettore e la PCB del modulo.
Scegliere un metodo di connessione Il compromesso si riduce all’opzione di utilizzare connettori modulari e cavi già pronti, che sono affidabili e robusti ma richiedono una serie di componenti adatti, oppure quella di creare le proprie connessioni, utilizzando ponticelli utilizzando jumper con terminali socket a crimpare oppure creandosi da soli il socket-header per un determinato modulo. Quale opzione scegliere dipende da quanta fatica volete fare per collegare moduli a una scheda Arduino o a una shield e quanto “chiuso” volete che sia un particolare schema di connessione. Potete aver notato che non ho parlato di un altro possibile metodo di connessione dei moduli: la saldatura. Questa è sempre un’opzione, ma, a meno che un modulo non sia destinato a diventare una parte permanente di qualcosa, dovrebbe essere considerata come l’ultima spiaggia. Saldando un modulo direttamente ai cavi o su una PCB si crea una connessione solida, ma non facile da disfare e probabilmente brutta da vedere. Significa anche se si disporrà di un modulo in meno da utilizzare in altri progetti. Detto questo, potete aver notato che nella Figura 9-12 il relè e moduli sensore di temperatura sono saldati direttamente in una shield di prototipazione per il termostato fatto con Arduino. Il motivo qui è che il modulo non verrà messo fuori servizio in tempi brevi e dovrà lavorare in un ambiente alquanto difficile, all’interno di una stufa elettrica, con fluttuazioni termiche e le vibrazioni del ventilatore. Per questo, ho scelto di renderlo relativamente permanente. Anche se a un certo punto potrei pentirmene, per adesso va bene così. Se vi si presenta l’occasione, dovrete essere voi stessi a decidere se è il
caso di saldare.
Fonti Le fonti elencati nella Tabella 9-11 sono soltanto un esempio di alcune delle società che vendono componenti e moduli compatibili con Arduino. Sono soltanto quelli che ho avuto occasione di conoscere e che ho potuto provare. Esistono molti altri rivenditori di cui non sono a conoscenza, ma potete scoprirli da soli navigando su Internet. E non dimenticatevi di eBay. Tabella 9-11 - Fonti di componenti.
Distributore/Venditore
URL
Distributore/Venditore
Adafruit
www.adafruit.com
Mouser Electronics
www.mous
Amazon
www.amazon.com
RobotShop
www.robot
CuteDigi
store.cutedigi.com
SainSmart
www.sains
DealeXtreme (DX)
www.dx.com
DFRobot
www.dfrob
Seeed Studio
www.seeedstudio.com
Elecfreaks
www.elecfr
SparkFun
www.sparkfun.com
Elechouse
www.elech
Tindie
www.tindie.com
Freetronics
www.freetr
Tinkersphere
tinkersphere.com
iMall
imall.itead.
Tronixlabs
tronixlabs.com
ITEAD Studio
store.itead
Trossen Robotics
www.trossenrobotics.com
KEYES
en.keyes-ro
Riepilogo Questo capitolo ha fornito un assaggio di alcuni dei vari moduli e componenti disponibili per implementare funzioni di input e di output con Arduino (o praticamente con qualsiasi microcontroller moderno). Come ho dichiarato in precedenza, potete trovare molte delle funzionalità descritte qui su una shield, ma possono esserci occasioni nella quali una shield non è la scelta più adatta. Con un Arduino Nano e alcuni sensori, componenti di input e alcuni tipi di output, potete organizzare le cose in modo che siano ideali per i vostri particolari requisiti. Con un browser web e l’accesso a Internet, potete trovare facilmente centinaia di diversi componenti I/O che possono essere collegati ad Arduino, o perfino soltanto un semplice IC AVR. Le fonti vanno da grandi distributori di elettronica, come DigiKey, Mouser e Newark/Element14, a società come Adafruit, SparkFun, SainSmart e
CuteDigi. Esistono anche distributori specializzati in componenti nuovi a basso costo e surplus. Quando si tratta di acquistare dei sensori per un progetto di Arduino, ecco alcuni punti da tenere a mente: 1. Il dispositivo utilizza un’interfaccia semplice (digitale discreta, SPI, I2C, ecc.)? 2. Il dispositivo è accompagnato da dati tecnici (o è immediatamente disponibile)? 3. Esistono librerie software di Arduino? A seconda del vostro livello di abilità con la programmazione, il punto 3 può rappresentare o meno un grosso problema per voi. Personalmente, ho messo molto di più l’accento sui punti 1 e 2, soprattutto perché ho cose migliori da fare che l’ingegneria inversa di un’interfaccia complessa di qualche cosa con davvero un bell’aspetto che ho comprato in offerta su eBay. Per me, ha più senso per comprare una cosa non-cosìbella e ottenere le informazioni tecniche di cui ho bisogno per installarla e farla funzionare. La cosa più importante è trovare qualcosa che farà il lavoro e a un prezzo non superi il nostro budget.
10 Creare componenti personalizzati
Più lavorate con dispositivi Arduino in generale e con il microcontroller AVR in particolare, più vi accorgete di quanto siano flessibili e versatili. Sembra che esista un sensore o una shield per quasi qualsiasi applicazione possiate immaginare e regolarmente appaiono nuove shield. Ciononostante, ci sono ancora alcune applicazioni per le quali non esiste una shield. Può succedere di passare ore online cercando invano una shield con determinate funzionalità, soltanto per accorgersi, alla fine, che semplicemente non esiste. In una situazione simile, fondamentalmente avete tre opzioni: la prima è arrendervi e cercare di trovare un altro modo di risolvere il problema, la seconda è trovare qualcuno che ve la costruisca (a pagamento, di solito) e la terza è progettare e costruirvi da soli la PCB. Questo capitolo descrive due progetti che illustrano i passaggi necessari per creare una shield personalizzata e un dispositivo compatibile con il software di Arduino. Il primo progetto è una shield, mostrata nella Figura 10-1, pensata per applicazioni di un determinato tipo. La GreenShield, come la chiamo io, si basa su un fattore di forma convenzionale. Utilizza componenti a montaggio superficiale in un layout che include potenziometri, relè e LED.
Figura 10-1 - La GreenShield.
Quando viene associata a un Arduino, la GreenShield può funzionare come un monitor indipendente e come un controller per applicazioni di giardinaggio o agricoltura. Questa shield può anche fungere da base per stazioni meteorologiche automatiche, per prevedere temporali, oppure come termostato (notate che un termostato programmabile costruito utilizzando moduli e sensori già pronti è descritto nel Capitolo 12). La seconda metà di questo capitolo descrive lo Switchinator, un dispositivo basato su AVR ATmega328 che non si appoggia al firmware del bootloader di Arduino, ma può essere comunque programmato con l’IDE di Arduino e con un dispositivo di programmazione ICSP. La PCB Switchinator è mostrata nella Figura 10-2.
Figura 10-2 - Lo Switchinator.
Lo Switchinator può controllare in remoto fino a 14 dispositivi DC come relè o LED ad alto consumo, gestire 3 motori passo-passo unipolari, oppure controllare carichi AC utilizzando relè a stato solido esterni. Utilizza un’interfaccia RS-232 e non richiede una connessione con un PC host via USB. Lo Switchinator incorpora tutti i componenti essenziali di un Arduino in una scheda con un design personalizzato. Non dovremo preoccuparci delle dimensioni dei socket header e delle considerazioni sul layout che richiedono le PCB delle shield: gli unici limiti per la dimensione generale e la forma saranno quelli imposti dal design. Con un po’ di pazienza e di pianificazione, potete facilmente creare una PCB personalizzata che non assomigli affatto a un Arduino, ma offra la stessa facilità di programmazione. E il bello è che farà esattamente quello per cui lo avete progettato e in una forma fisica che risponde esattamente alle vostre esigenze. Creare una PCB non è particolarmente difficile, ma si tratta di un’operazione che richiede alcune conoscenze di design delle PCB e di elettronica. Esistono strumenti software gratuiti o a basso costo che servono a gestire la creazione del layout della
PCB e in realtà procurarsi una scheda a circuito pronta è piuttosto facile. I progetti mostrati in questo capitolo richiederanno anche che sappiate saldare, specialmente nel caso dei componenti a montaggio superficiale. Se avete già esperienza in questi campi, siete preparati. In caso contrario, imparare come creare uno schema, a lavorare con le PCB, a utilizzare una saldatrice e a selezionare i componenti giusti può rivelarsi un’esperienza divertente e appagante. Per la PCB della shield, utilizzeremo lo strumento per la cattura degli schemi e il layout della PCB Eagle, mentre per la PCB compatibile con Arduino utilizzeremo lo strumento Fritzing. Entrambi sono strumenti molto diffusi e potenti. Inoltre sono gratuiti (in realtà, Fritzing è gratuito e la versione entry-level di Eagle, con alcuni limiti, è disponibile a prezzo zero). NOTA Quando create shield personalizzate o schede compatibili con Arduino, potete farvi un favore enorme mantenendo un quaderno di appunti. Anche se non si tratta di nient’altro che di una raccolta di pagine stampate o fotocopiate in un raccoglitore ad anelli, sarete contenti di averlo quando in futuro avrete bisogno di cercare alcune informazioni per un progetto simile. Perché non salvarle semplicemente tutte sul disco del vostro PC? Perché rischiare di perderle se il disco si danneggia senza un backup, o nella folla di dati se ci sono già moltissime cose salvate sul disco (questo a me succede più spesso di quanto non ammetta). Inoltre, raccoglierle in un quaderno di appunti vi permette di ritornarci in seguito e di annotarvi cose man mano che diventate più esperti testando, costruendo e utilizzando il vostro dispositivo. Le penne rosse non servono soltanto ai professori.
Questo capitolo propone inoltre un elenco di fonti dove trovare software, componenti e PCB. L’unica cosa che ho dato per scontata è che abbiate già qualche esperienza con l’elettronica o che almeno vogliate fare un piccolo sforzo extra per impararne i concetti fondamentali. Vi consiglio di dare un’occhiata alla breve panoramica degli strumenti nell’Appendice A e certamente di sfogliare le letture suggerite nell’Appendice D. Infine, non dimenticate di approfittare degli articoli che si trovano su siti web come Hackaday (http://hackaday.com/), Makezine (http://makezine.com/), Adafruit (http://www.adafruit.com/), SparkFun (http://www.sparkfun.com/) e Instructables (http://www.instructables.com/). Potete trovare anche tutorial video su YouTube. Molti altri hanno percorso gli stessi sentieri prima di voi e molti di loro sono stati così gentili da documentare le loro avventure a vantaggio di altri. NOTA Ricordate che, dal momento che in questo libro l’accento è posto principalmente sull’hardware di Arduino e sui relativi moduli, sensori e componenti, il software mostrato qui ha l’unica intenzione di sottolineare i punti chiave e non di presentare esempi completi e pronti da utilizzare. I codici completi dei software relativi a esempi e progetti si trova su GitHub (https://www.github.com/ardnut).
Per cominciare Nel caso di qualsiasi impresa, vale la pena dedicare una significativa quantità di tempo alla pianificazione. Questo vale per i progetti di elettronica esattamente come per lo sviluppo e l’implementazione di software complesso, per la costruzione di una casa, per la progettazione di un’automobile per le gare di Formula 1, oppure per la preparazione di una spedizione nell’Artico. Come dice un vecchio adagio: “Fallire una pianificazione è
pianificare di fallire”. Tutti i progetti, eccetto quelli più banali, possono essere suddivisi in una serie di passaggi. In generale, per creare un dispositivo elettronico sono necessari sette passaggi fondamentali: 1. Definire 2. Pianificare 3. Progettare 4. Prototipare 5. Testare 6. Produrre 7. Collaudare Alcuni progetti possono presentare meno passaggi e altri di più, a seconda di che cosa si costruisce. Ecco qualche dettaglio in più su ciascun passaggio: Definire Nei termini dell’ingegneria formale, si riferisce alla fase di definizione dei requisiti, o, più correttamente, alla fase di definizione dei requisiti funzionali. Nei casi più semplici, è sufficiente una breve descrizione di che cosa farà il risultato finale del progetto e di come sarà utilizzato. Nei casi più complessi, come per esempio quello di una shield da utilizzare con un Arduino su un CubeSat, probabilmente diventa necessaria una descrizione più dettagliata. Ma, a prescindere dalla complessità, scriverlo può aiutare a tenere traccia dei passaggi che seguono e può anche rivelare alcuni errori e omissioni che altrimenti potrebbero passare inosservati fino a che non diventa troppo tardi per apportare facilmente modifiche sostanziali. Infine, è una buona idea scrivere la definizione del progetto in modo che possa essere utilizzata come un prototipo oppure un dispositivo finito. Se i requisiti funzionali non dichiarano in modo chiaro che cosa deve fare il dispositivo in modo che qualcuno possa utilizzare questa descrizione per testarlo, significa che in realtà non si tratta di una buona serie di requisiti e che non definisce molto bene il dispositivo o il sistema desiderato. Scrivere requisiti funzionali può sembrare noiosissimo, ma in realtà si tratta di un aspetto essenziale dell’ingegneria. Se non sapete dove volete andare, come potete sapere quando ci arrivate? Un buon requisito, di qualsiasi tipo, deve avere quattro caratteristiche essenziali: (1) deve essere in accordo con se stesso e con il design complessivo, (2) deve essere coerente in modo da avere senso, (3) deve essere conciso e non eccessivamente prolisso e (4) deve essere verificabile. Un requisito funzionale che dichiara che “Il dispositivo deve poter scaldare 100 millilitri d’acqua in un contenitore da 250 ml portandola a 100 gradi C in 5 minuti” si può testare, ma una dichiarazione come “Il dispositivo deve poter scaldare l’acqua” non lo è (Quanto calda? In quanto tempo? Quanta acqua?).
Pianificare A volte la pianificazione e la definizione possono avere luogo nel corso dello stesso passaggio, se il dispositivo è qualcosa di relativamente semplice e facile da capire. In ogni caso, però, il passaggio relativo alla pianificazione riguarda le informazioni necessarie per il passaggio relativo alla progettazione e comporta l’ottenere più informazioni essenziali possibile in un unico posto (cose come le schede tecniche dei componenti, dove reperire le parti, l’identificazione del design necessario e degli strumenti software e così via). L’idea è arrivare al passaggio relativo alla progettazione con tutto il necessario per prendere le decisioni giuste su che cosa è disponibile, quando può volerci per procurarselo e come lo si utilizzerà. Il passaggio della pianificazione è anche il momento in cui si formulano alcune timide ipotesi su quanto si impiegherà per completare ciascuno dei passaggi successivi: progettazione, prototipazione, test, produzione e collaudo. Dico “timide ipotesi” perché dopo aver raccolto più informazioni possibile si dovrebbe avere qualche idea di che cosa servirà, ma queste sono soltanto ipotesi perché nessuno ha la sfera di cristallo per vedere il futuro. Possono sempre presentarsi degli imprevisti e a volte il completamento di alcuni aspetti del progetto può richiedere più tempo di quello che si era pensato. Così vanno le cose nel mondo reale. Questo è anche il motivo per il quale chi si occupa di project management da una vita moltiplica i tempi che stima per un fattore di due o tre. È meglio esagerare e finire il lavoro prima che sottovalutare la quantità di tempo necessario e consegnarlo tardi. Uno strumento di pianificazione si rivela utile sia per prevedere la tempistica in modo realistico, sia come modo per valutare i progressi. Il mio strumento preferito per pianificare in modo rapido e semplice è il grafico temporale, detto anche diagramma di Gantt. Questi possono essere diagrammi complicati creati utilizzando un software di gestione dei progetti, oppure grafici semplici come quello mostrato nella Figura 10-3.
Figura 10-3 - Un grafico temporale di esempio.
Nel caso di molti progetti piccoli, i grafici elaborati non sono necessari e la complessità aggiuntiva non è altro che lavoro in più. Le cose importanti sono che: (1)
nella pianificazione si tenga conto di tutti i compiti necessari, (2) il piano sia realistico sia dal punto di vista del tempo che delle risorse e (3) il piano abbia un obiettivo e un termine precisi. Un’altra cosa da notare sul semplice grafico temporale è che alcuni compiti cominciano prima che il precedente sia stato completato e il grafico non mostra le dipendenze che indicherebbero un percorso critico. Io ho scoperto che, nel caso di piccoli progetti che coinvolgono soltanto una o due persone, questa programmazione sovrapposta riflette in modo più realistico come avvengono realmente le cose. Progettare Nel caso di un progetto hardware, il passaggio relativo alla progettazione è quello nel quale cominciano a emergere i diagrammi dei circuiti e prende forma il design di della forma fisica. Tenendo sotto mano la definizione del progetto e le informazioni sulla pianificazione, dovrebbe risultare chiaro che cosa è necessario fare. Anche se, quando si parla di progettazione, quasi tutti pensano alla definizione dei circuiti, questo passaggio include altre attività significative come la selezione dei componenti in base a forma e dimensione, la valutazione del consumo elettrico dei componenti e delle considerazioni ambientali (umidità, vibrazioni e temperatura) e magari anche potenziali problemi di RFI (radio frequency interference). Quando si progetta un nuovo dispositivo, si devono sempre effettuare delle scelte. A volte, il motivo per preferire un metodo a un altro si riduce al costo e alla disponibilità di componenti o materiali. Un’altra considerazione è la funzionalità prevista, come nel caso in cui un controllo di input deve poter eseguire più di una funzione. Altre volte, la scelta può basarsi su fattori estetici, in particolare se non vi è nessuna differenza di costo se si sceglie un modo piuttosto che un altro. Infine, in alcuni casi è soltanto una questione di utilizzare qualcosa che è noto e familiare, piuttosto che lavorare con qualcosa che non si conosce. Questa non sempre è la migliore ragione per operare una scelta, ma succede abbastanza spesso. Indipendentemente dal tipo di progetto (hardware, software, struttura o qualsiasi altra cosa), di solito la fase di progettazione è iterativa. Non è realistico aspettarsi che la progettazione riuscirà al primo tentativo, a meno che non si tratti di qualcosa di profondamente banale (e anche in quel caso non si può essere sicuri). In realtà, la progettazione e la prototipazione (che vedremo tra poco) lavorano insieme per identificare i potenziali problemi, elaborare soluzioni praticabili e perfezionare il design. Questo è comune in ingegneria e, anche se a volte è irritante, l’iterazione è una parte essenziale del perfezionamento della progettazione. Prototipare Per cose semplici, come shield I/O di base senza circuiti attivi, costruire un prototipo può non essere strettamente necessario (o addirittura possibile). In altri casi, si può utilizzare un prototipo per verificare il design e assicurarsi che si comporti secondo la definizione creata all’inizio del progetto. Per esempio, può non essere una buona idea saltare subito al layout di una PCB nel caso di un dispositivo che combina un
processore AVR, un display LCD, una ricetrasmittente Bluetooth, un accelerometro multiassiale e una bussola elettronica, tutti sulla stessa PCB. Tutto può funzionare al primo tentativo, ma, se ci fossero piccoli problemi imprevisti, possono non diventare apparenti finché la PCB non è già stata creata e pagata. Costruire e testare prima un prototipo può far risparmiare molti problemi e denaro più avanti. I problemi che si identificano con un prototipo influenzano il design per contribuire a migliorarlo. In un caso estremo, il prototipo può addirittura dimostrare che il design iniziale è sbagliato e deve essere rifatto da capo. Anche se questo è fastidioso, non è un disastro (in realtà, è più comune di quanto possiate pensare). Costruire un centinaio di schede a circuito soltanto per scoprire che c’è un difetto di progettazione fondamentale: questo è un disastro. I prototipi, i test e le revisioni del design possono evitare che questo succeda.
Modifiche e ancora modifiche Durante il suo sviluppo, il generatore di segnale mostrato nel Capitolo 11 è passato per diverse revisioni principali. Il piano originale mirava alla possibilità di disporre di un controllo remoto di tutte le funzioni del generatore attraverso un’interfaccia seriale RS-232 e una funzione di output parallela con una specifica configurazione digitale. Il problema è che su Arduino non ci sono abbastanza pin I/O on per far succedere tutto questo senza ricorrere all’utilizzo di shield di espansione I/O ed RS-232. Per risolvere questi problemi si sarebbero potute utilizzare altre opzioni, come utilizzare un encoder rotativo, ma ogni alternativa proponeva delle sfide. Lo strumento aveva comunque bisogno di pulsanti per alcune funzioni e l’LCD stava cominciando a diventare davvero piccolo in termini di spazio di visualizzazione disponibile. Quindi, anziché incorporare altra complessità sia nell’hardware che nel software, ho deciso di puntare alla semplicità. Il design che ne ha risultato non utilizza interrupt nel software (non ce n’è bisogno), l’LCD non è troppo affollato di valori di dati criptici e sono necessari soltanto due componenti PCB principali: la scheda Arduino e il modulo DDS. Il dispositivo finale offre sufficienti funzionalità come generatore di segnale, anche se non è dotato di un pattern output arbitrario o di un controllo remoto.
Testare L’essenza dei test è semplice: “Fa correttamente quello che deve fare e lo fa in modo sicuro e affidabile come dovrebbe?”. La definizione del progetto creata in via preliminare è il criterio che si utilizza per determinare se il dispositivo presenta le funzionalità desiderate e mostra la sicurezza e l’affidabilità richieste. Questi sono i testi funzionali di base. Possono diventare molto più complicati, ma, a meno che non prevediate di inviare il vostro progetto nello spazio (o in fondo all’oceano) o che il dispositivo non debba controllare qualcosa che costerebbe moltissimo denaro se non funziona a dovere (o danneggiare qualcos’altro, come per esempio esseri umani), per il prototipo dovrebbero essere sufficienti i test funzionali di base. Una parola sulle differenze tra “corretto”, “sicuro” e “affidabile”: il semplice fatto che qualcosa si comporti nel modo corretto non significa che sia sicuro (sicuro può anche significare “funziona senza rischi inaccettabili”) e qualcosa che si comporta in un modo sicuro non è necessariamente corretto e nemmeno affidabile. Se un dispositivo non si accende, può essere considerato sicuro e affidabile (possiamo essere certi che non fa niente), ma definitivamente non corretto. Infine, dire che un
dispositivo è corretto e affidabile non implica automaticamente che sia sicuro. Un utensile come una sega circolare palmare può tagliare la legna in modo corretto e affidabile, ma in modo corretto e affidabile potrebbe anche tagliare una mano con la stessa facilità. Un dispositivo elettrico con un corto circuito interno emetterà fumo in modo affidabile (e forse anche qualche fiamma) quando gli si fornisce alimentazione, ma il funzionamento generale non sarà né sicuro né corretto. Produrre Dopo che il prototipo è stato testato e ha dimostrato di avere un comportamento corretto in accordo con i requisiti funzionali, il design può passare alla fase della produzione. Questo passaggio comporta la produzione di una PCB sulla quale successivamente si montano le parti. Può anche riferirsi all’integrazione dei moduli pronti e dei cavi e fili associati in un contenitore o in un sistema più ampio. In termini di possibili ritardi, la produzione può essere problematica. Un fornitore può aver esaurito un componente fondamentale, oppure, se si è affidato l’assemblaggio a qualcuno, questa azienda può avere dei problemi o un sovraccarico di lavoro. Le parti personalizzate possono arrivare tardi per numerosi motivi. Fortunatamente, se avete intenzione di produrre soltanto alcune unità di qualcosa e vi occupate di tutta la produzione voi stessi, potete evitare molti di questi problemi potenziali. Comunque, concedersi molto tempo non fa mai male. Andare di corsa in ferramenta per comprare una scatola di viti a testa tonda 6-32 da 3/8 pollici richiede del tempo e se non ce le hanno ce ne vuole ancora di più per cercarle in un altro negozio. Ovviamente, se avete eseguito i passaggi di progettazione e pianificazione tenendo presente che cosa sarebbe stato necessario per la produzione, dovreste disporre di tutti i componenti, le PCB, le viti, i dadi, bulloni, le rondelle, i connettori, i fili, le staffe e la colla che vi servono. Collaudare Questo ultimo passaggio è noto anche come test finale, dal momento che è l’ultima cosa da fare prima che il dispositivo si possa considerare pronto per l’utilizzo o per la distribuzione. Alcuni test funzionali di base sono già stati svolti durante la fase di prototipazione, ma adesso è il momento di testare il prodotto finale. Questo non è affatto uno sforzo duplicato. Montare una parte sbagliata sulla PCB, o addirittura installare una parte al contrario, è davvero facile. Inoltre, a volte i circuiti della PCB si comportano in modo diverso da quelli costruiti sulla scheda di prototipazione senza saldature e quindi testare accuratamente il dispositivo assemblato è sempre una buona idea. Il test di solito si svolge in due passaggi. Il primo passaggio verifica che il dispositivo o il sistema si comporti nello stesso modo del prototipo. L’idea è applicare gli stessi test utilizzati con il prototipo per verificare che non sia cambiato niente. Nell’ingegneria software, questo viene detto test di regressione. Il passaggio successivo comporta ulteriori test per verificare che quello che si è costruito funzioni correttamente nella sua configurazione finale con I/O reali. Questo è il motivo per cui
questo passaggio viene detto prova di collaudo e il punto principale è rispondere alla domanda: “Il dispositivo o il sottosistema è accettabile per l’applicazione per la quale è pensato?”.
Le shield personalizzate Fondamentalmente, esistono tre tipi principali di fattori di forma da considerare quando si progetta una shield per Arduino. Si tratta dei layout dei pin di base, esteso e Mega. Quello originale o di base (l’R2), che si trova sulla Duemilanove, sull’Uno R2 e su altre schede più vecchie, può essere considerato lo standard per il layout delle shield, ma questo non significa che una shield non possa essere progettata in modo che utilizzi il layout esteso (l’R3) che si trova sui modelli più recenti delle schede Uno e Leonardo. Le shield possono essere progettate anche in modo che utilizzino tutti i pin di un Arduino in stile Mega e non c’è motivo per cui una shield debba avere la stessa forma di un Arduino. Alcune shield, come quelle dotate di relè o di grandi dissipatori, hanno un fattore di forma fisico adatto ai loro componenti, anziché all’Arduino al quale sono collegate. Un approccio innovativo che ignora i limiti di dimensione è creare una grande PCB con una serie di pin sistemati in modo che un Arduino possa essere collegato in posizione invertita. Questo potrebbe suonare strano, ma date un’occhiata alla Figura 10-4. Qui vedete la scheda di una fresatrice CNC Roland SRM-20. Trovate maggiori informazioni su di essa sul blog infosyncratic.nl di Nadya Peek (http://bit.ly/open-hardware-footbath).
Figura 10-4 - Un Arduino invertito su una PCB grande (immagine di Nadya Peek).
Se volete progettare una shield da mettere in commercio, vi conviene utilizzare il layout
di base come modello, dal momento che funzionerà anche con le schede Uno o Leonardo, oltre che con le PCB di tipo Mega. Il Capitolo 4 descrive ciascuno di questi tipi di scheda e fornisce le dimensioni e le informazioni sul pinout. Le schede Arduino con un fattore di forma piccolo come la Nano, la Mini e la Micro sono uniche, per il fatto che hanno tutti i loro pin I/O sulla parte inferiore della PCB, anziché come un grande IC. Aggiungere una shield a una di queste schede comporta l’utilizzo di un adattatore, come quello mostrato nella Figura 10-5, per collegare i segnali ai pin socket e collegare la PCB di una shield PCB.
Figura 10-5 - La PCB dell’adattatore di un Arduino Nano.
Nella Figura 10-5 potete notare che i pin socket sono state aggiunte alla PCB. Questo è stato un esperimento, per vedere come si sarebbe potuto fare per interfacciare fisicamente una scheda Nano con una shield normale. Con un po’ di creatività, è possibile collegare una shield alla scheda, eccetto che per il fatto che la Nano è troppo elevata sui pin socket. Una soluzione potrebbe essere utilizzare estensioni per i pin della shield, che non sono altro che socket header di estensione con eliminata una parte della lunghezza dei pin. Una soluzione più drastica potrebbe essere dissaldare gli header esistenti della Nano e sostituirli con un tipo più corto. Io consiglio l’opzione dell’estensione dei pin. Questo capitolo non analizza i passaggi necessari per creare questo tipo di adattatore. Utilizzare qualcosa come un Arduino Nano, Mini o Micro con una shield in realtà non ha molto senso la maggior parte delle volte (anche se nel Capitolo 12 c’è un esempio dove lo si è fatto per una particolare applicazione). Ha senso trattare queste piccole PCB come se fossero grandi circuiti integrati e utilizzarli come componenti su una PCB grande.
Considerazioni fisiche Dovete ricordare che sulla PCB della Duemilanove e probabilmente anche di altre schede ci sono due condensatori a montaggio superficiale che possono urtare i pin extra che si trovano sulla riga dell’alimentazione e del connettore analogico di alcune shield progettate per il layout R3 esteso. Anche alcune varianti della Uno presentano componenti che urtano i pin delle shield. Un’altra considerazione è che il tipo di jack B USB che si trova sulle schede Duemilanove e Uno può fare corto circuito con la PCB delle shield. Anche il jack dell’alimentazione DC di queste schede può interferire con la PCB delle shield. Anche se è di plastica e non farà corto circuito con niente, può impedire alla shield di collocarsi completamente. La Figura 10-6 mostra questa situazione con una scheda Duemilanove e una shield Ethernet.
Figura 10-6 - Una scheda Duemilanove con una shield.
Per questi motivi, conviene regolare la lunghezza della shield in modo che non interferisca con l’Arduino sottostante, oppure progettare la posizione dei componenti sulla PCB della shield in modo da lasciare vuote le zone di collisione. Nel prossimo paragrafo, nel Capitolo 4 e nel Capitolo 8 trovate maggiori informazioni sulle dimensioni delle PCB e su come si montano le shield l’una sull’altra. Quando si progetta una shield, si deve anche pensare a quello che non sarà più accessibile sulla scheda Arduino sotto di essa e a che cosa vi si può montare o meno. Questo include il pulsante di reset, i LED a montaggio superficiale e il gruppo di pin ICSP. Alcune shield risolvono questo semplicemente replicando il pinout della scheda Arduino. Altre, come la maggior parte delle shield LCD, possono non replicare i pin di Arduino sulla parte superiore della PCB della shield, ma a volte mettono a disposizione
un pulsante di reset. Nel caso di una shield LCD questo ha senso, naturalmente, dal momento che in ogni caso si tratterebbe della shield al di sopra di tutte le altre.
Montare le shield una sopra l’altra Uno dei vantaggi offerti dal fattore di forma di Arduino è la possibilità di montare diverse shield una sopra l’altra. Potete creare una pila che contiene una scheda Arduino di base (una Uno, per esempio) con sopra una shield con lettore di schede di memoria SD, seguita da una shield input/output di qualche tipo e quindi una shield con display LCD o TFT al di sopra di tutto. In questo modo ottenete facilmente un semplice dispositivo di logging dei dati. Quello che può essere montato sopra una shield dovrebbe essere sempre pensato bene, che si tratti di un’altra shield o magari di un modulo sensore di un qualche tipo. Quando si selezionano i componenti per una shield, si deve prendere in considerazione l’altezza delle varie parti. Se le parti sono troppo alte e non si può collegare fisicamente un’altra shield senza che interferisca con qualcosa, significa che quella shield dovrà sempre essere quella al di sopra di tutte. Esistono fondamentalmente due modi di montare diverse shield l’una sopra l’altra: prese sfalsate e header di pin e pin socket estese. Sfalsate, in questo contesto, significa che i connettori superiori (le prese) sono leggermente spostati rispetto ai pin inferiori (gli header dei pin), con gli header I/O digitale e alimentazione/analogico entrambi spostati sul lato della stessa distanza. Nella Figura 10-7 potete vedere una shield I/O modulare su una Duemilanove. Qui ci sono alcune cose da notare. La prima è che la shield I/O modulare utilizza l’approccio dei connettori sfalsati e quindi il bordo non è allineato verticalmente con la scheda Arduino sottostante. Questo deve essere tenuto presente se il tutto deve essere montato in una custodia di un qualche tipo che può essere soggetta a colpi o vibrazioni (può non essere possibile fissare la shield con dadi e bulloni). La seconda cosa da notare è che la shield non collega i pin ICSP e quindi la funzionalità viene effettivamente persa (cosa che può rappresentare un grosso problema o meno). Infine, i pin dei connettori sul bordo della shield al di sopra dell’alimentatore dell’Arduino e del connettore USB possono (e lo fanno) toccarsi e quindi è necessario aggiungere uno strato isolante di qualche tipo.
Figura 10-7 - Un esempio di shield sfalsata.
I connettori extended pin socket sono una variante comune sui connettori 0.1 (pollici) dotati di un pin lungo che attraversa la PCB. Il pin è sufficientemente lungo da creare una connessione solida con una scheda sottostante e le prese dei connettori permettono di montare un’altra scheda shield sopra e di allinearsi con la shield sottostante. Questi si trovano su molte shield e dovete cercarli quando scegliete una shield. Una considerazione importante che riguarda il design delle shield è l’uso dei pin di Arduino, oltre alla possibilità di montarle una sopra l’altra. I pin utilizzati da una shield determinano che cos’altro si può utilizzare con quella shield in una pila. Evitare l’uso esclusivo dei pin SPI e I2C significa poter utilizzare altre shield in una pila, comprese memorie flash SD e microSD, shield d’espansione I/O, Bluetooth, ZigBee, Ethernet e GSM. In altre parole, è meglio non riutilizzare i pin SPI o I2C a meno che il design della shield non ne abbia assolutamente bisogno. A volte potete trovare shield che secondo qualcuno sono un’ottima idea, ma che nella pratica non sempre funzionano bene. Spesso le shield I/O sono dotate di diversi blocchi di pin di connettori che diventano inaccessibili se vi si posiziona sopra un’altra shield. Altre shield hanno piazzole di saldatura che interferiscono con i pin ICSP della PCB di Arduino. Problemi come questi non sono infrequenti. Purtroppo, non sempre è possibile sapere in anticipo se ci sono difficoltà con una shield e a volte l’unico modo per sapere se una determinata shield può presentare problemi con il montaggio fisico è acquistarla e provarla.
Considerazioni elettriche Se le vostre shield personalizzate non contengono altro che componenti passivi (cioè, connettori, interruttori, resistenze), probabilmente i requisiti relativi alla loro
alimentazione non rappresenteranno un problema. Se invece sono dotate di LED o di altri circuiti attivi, conviene calcolare in anticipo di quanta alimentazione avranno bisogno e da dove la prenderanno. Anche un dispositivo semplice come un LED consuma un po’ di corrente e utilizzandone vari si rischia di sovraccaricare il processore AVR e di fare danni. Come regola generale, se una shield contiene uno o più relè o connettori per collegare cose che possono richiedere più di qualche milliamp l’una, conviene aggiungere un circuito o un IC driver di un qualche tipo. È possibile alimentare una shield con un alimentatore separato, ma a volte passare i segnali tra la scheda Arduino e la shield può rivelarsi difficile. Se una shield ha il suo proprio alimentatore DC, si deve pensare anche alla messa a terra. Sull’Arduino di base ci sono tre prese per la messa a terra: due sul lato con gli input analogici e una sul lato degli I/O digitali. Se utilizzate soltanto una delle prese della messa a terra di Arduino per il riferimento della messa a terra del segnale di una shield, potete evitare problemi potenziali con rumore indotto e loop di massa. Anche se queste situazioni sono molto rare, rappresentano comunque una possibilità, in particolare nel caso di shield che possono incorporare amplificatori operazionali ad alto guadagno o circuiti ad alta frequenza. Applicare buone pratiche di design può aiutare a evitare problemi strani e difficili da diagnosticare nel futuro.
La shield personalizzata GreenShield In questo paragrafo creeremo una shield personalizzata per illustrare i passaggi necessari per progettare e produrre una shield per Arduino. La shield servirà a controllare l’umidità, la temperatura, l’illuminazione dell’ambiente e l’umidità del suolo. È pensata principalmente per essere utilizzata in una serra, anche se, con una custodia adeguata, qualche pannello solare e una ricetrasmittente wireless di qualche tipo può essere messa in un campo per controllare le rape (o qualsiasi altra cosa). Dal momento che in alcune parti del mondo (tra le quali gli Stati Uniti orientali) l’acqua scarseggia, tenere d’occhio l’umidità del suolo oltre alla temperatura e all’umidità può aiutare a ridurre al minimo i tempi e i volumi di irrigazione mantenendo comunque in buona salute le coltivazioni. L’agricoltore può rimanere seduto in salotto e leggere rapidamente come vanno le cose nel suo campo per mezzo di uno smartphone, di un tablet o di un PC desktop. Io la chiamo GreenShield, per ovvie ragioni, e i passaggi relativi a definizione e progettazione sono combinati in un unico passaggio. Dal punto di vista fisico, la GreenShield è molto semplice e la sfida principale per il design dell’hardware sarà riuscire a far stare alcuni componenti grandi (due relè e un DHT22) nella piccola PCB della shield.
Obiettivi L’obiettivo di questo progetto è creare una shield che possa essere utilizzata come
monitor remoto che rilevi la temperatura, l’umidità, l’umidità del suolo e il livello di illuminazione dell’ambiente. Basata sui limiti predefiniti degli input dei sensori, controllerà due relè. I relè possono essere utilizzati per controllare una valvola dell’acqua e magari un ventilatore o forse qualche luce per compensare nei giorni nuvolosi. Ha anche sei LED: due per i punti d’umidità alta e bassa, due per i livelli di umidità del suolo alto e basso e un LED per indicare l’attività di ciascun relè. Il software supporterà un protocollo comando-risposta e manterrà una tabella interna delle funzioni automatiche dei relè mappate sui limiti e gli input dei sensori. In alternativa, un computer host può ottenere i risultati dei sensori su richiesta e controllare direttamente i relè.
La definizione e la pianificazione La shield incorporerà una combinazione di sensore di temperatura e umidità DHT22, un sensore LDR (light-dependent resistor, vedere Capitolo 9) per rilevare il livello di luminosità dell’ambiente e un sonda per l’umidità del suolo basata sulla conduttività. Due relè forniranno il comando automatico o su richiesta dei dispositivi o dei circuiti esterni. Gli input dei sensori: •
Temperatura
•
Umidità relativa
•
Umidità del suolo (relativa)
•
Livello di luminosità dell’ambiente
Controllo e output di stato: •
Due relè di controllo, funzione del software definibile, capacità 10 A
•
Quattro LED che indichino i limiti dell’umidità del suolo e dell’umidità
•
Due LED che indichino lo stato dei relè
Interfaccia elettrica: •
Morsettiera da due posizioni per l’input della sonda di umidità
•
Morsettiera da due posizioni per la connessione degli LDR
•
Morsettiera da tre posizioni per relè (NC, C e NO)
•
+5 V DC fornita dalla scheda Arduino collegata
Interfaccia di controllo: •
Protocollo comando-risposta, gestito dall’host di controllo
•
Risultati dei sensori disponibili su richiesta
•
Sostituzione dei relè da parte dell’host di controllo
Tutti i componenti saranno collocati su una shield standard di tipo base, con dimensioni come quelle descritte nel Capitolo 4. La maggior parte dei componenti saranno del tipo a montaggio superficiale, a eccezione delle morsettiere, dei relè e del sensore di temperatura e umidità DHT22.
Il design La GreenShield è pensata per essere utilizzata senza un display né controlli utente. In altre parole, questo dispositivo insieme a un Arduino funzionerà come controller e come sensore remoto autonomo. Può essere collegato a un altro sistema informatico (un computer che sia l’host principale) per ricevere parametri operativi, restituire i dati dei sensori e sostituire l’azione dei relè. Autonomo in questo caso significa che la GreenShield potrà azionare i relè automaticamente quando si verificano determinate condizioni, come certi livelli di umidità, di umidità del suolo o di illuminazione. Il software accetterà comandi inviatigli da un computer master per impostare i vari livelli di soglia e sostituire l’azione dei relè. Genererà una risposta su richiesta che contenga il livello corrente di temperatura, di umidità e di illuminazione e gli stati dei relè. Tutte le interazioni tra l’host di controllo e la GreenShield Arduino saranno transazioni comando-risposta. Il software della GreenShield sarà sviluppato interamente con l’IDE di Arduino. Il computer host utilizzato per compilare e caricare il codice completo fungerà anche da interfaccia per testare il codice in esecuzione su Arduino. Idealmente, si potrebbe pensare di creare un programma di interfaccia personalizzato utilizzando qualcosa come per esempio Python, o, in un ambiente Windows, un emulatore di terminale come TeraTerm (https://ttssh2.osdn.jp/index.html.en). Include un eccellente ambiente di scripting e ve lo consiglio vivamente.
Lo strumento per schemi e PCB Eagle Per questo progetto, utilizzo lo strumento per schemi e PCB Eagle. Se non ve lo siete già procurato, potete scaricarlo da http://www.cadsoftusa.com/download-eagle. La maggior parte delle distribuzioni principali di Linux ne hanno una versione più vecchia disponibile nei loro repository di pacchetti. Sul sito web di CadSoft, i limiti della versione gratuita di Eagle sono indicati come: •
L’area utilizzabile della scheda è limitata a 100 × 80 mm (4 × 3,2 pollici).
•
Si possono utilizzare soltanto due livelli di segnali (Top e Bottom).
•
L’editor di schemi può creare soltanto due fogli.
Le dimensioni di base di Arduino sono approssimativamente 69 mm × 53 mm e quindi non ci sono problemi se si vuole utilizzare Eagle per una shield del tipo di base o esteso. Non può essere utilizzato per creare una shield per un Arduino con PCB di tipo Mega, per via dei limiti imposti alle dimensioni. Il limite dei due livelli di solito non rappresenta un problema per la maggior parte dei design di shield, ma, in alcuni casi, le shield che elaborano segnali video o RF possono avere bisogno di ulteriori livelli per la messa a terra e l’alimentazione. I ragazzi di SparkFun offrono alcuni tutorial online chiari e concisi che aiutano a installare e utilizzare il software Eagle. Potete trovarli su http://bit.ly/sparkfun-eagle e http://bit.ly/sparkfun-using-eagle. Potete ottenere anche i componenti libreria Eagle PCB sul repository GitHub (https://github.com/sparkfun/SparkFun-Eagle-Libraries) di SparkFun. Ho scoperto che le librerie di SparkFun non funzionavano con la versione del pacchetto di Eagle utilizzata da Kubuntu 12.04 (l’ultima versione di Eagle
disponibile è la 5.12), ma la versione più recente di CadSoft (la versione 7.4.0) si installa e funziona bene. Io ho scelto la via più corta e ho installato la 7.4.0 con la 5.12 già installata, ho copiato il vecchio eseguibile di Eagle che si trova in /usr/bin in eagle.old e ho creato un link simbolico in /usr/bin che puntasse alla versione più recente in /opt/eagle-7.4.0/bin.
Le funzionalità La prima considerazione è il design fisico della PCB della shield. Il diagramma a blocchi mostrato nella Figura 10-8 propone una panoramica di quali tipi di funzioni presenterà la shield.
Figura 10-8 - Il diagramma a blocchi della GreenShield.
Notate che nella Figura 10-8 nessuna delle funzioni hardware interagisce direttamente. I sensori, i LED e i relè sono soltanto estensioni delle funzionalità I/O di base di Arduino. Il sensore di umidità/ temperatura è montato sulla PCB, mentre volendo la fotocellula
(un LDR, light-dependent resistor) e la sonda dell’umidità del suolo possono essere posizionati fuori dalla scheda. Per le connessioni del sensore si utilizzano morsettiere in miniatura, in modo che non sia necessario saldare né crimpare i connettori. La GreenShield è pensata per essere l’ultima (quella più in alto) shield di una pila. Questo è dovuto ai relè e al sensore di temperatura/umidità, che sono tutti abbastanza alti da non permettere di montarvi sopra un’altra shield.
L’hardware Dal punto di vista dei circuiti, la GreenShield non è molto complicata, come si può vedere nello schema mostrato nella Figura 10-9. Per gestire i LED di stato e i due relè, si utilizza un ULN2003A. Per salvare nel buffer il livello di tensione proveniente dal sensore di umidità del suolo e dell’LDR per l’input da inviare all’ADC dell’AVR, si utilizza un amplificatore operazionale duale. I sensori collegati agli input dell’amplificatore operazionale sono in realtà resistenze variabili e con i due potenziometri dei trimmer formano un divisore di tensione. I trimmer possono essere regolati in modo da ottenere una risposta ottimale dall’amplificatore operazionale senza spingerlo troppo a un estremo o all’altro dal punto di vista della tensione.
Figura 10-9 - Lo schema della GreenShield.
La GreenShield è stata progettata per permettere di estendere la pila di shield di Arduino evitando i pin I/O digitali e analogici importanti. La Tabella 10-1 elenca i pin di Arduino e le assegnazioni utilizzate per la GreenShield.
Tabella 10-1 - L’utilizzo dei pin di Arduino della GreenShield.
Pin
Funzione
Pin
Funzione
D2
ULN2003A canale 1
D7
ULN2003A canale 6
D3
ULN2003A canale 2
D8
Input di dati DHT22
D4
ULN2003A canale 3
A0
Input sensore umidità del suolo
D5
ULN2003A canale 4
A1
Input sensore LDR
Notate che i pin SPI (D10, D11, D12 e D13) non sono utilizzati e quindi rimangono disponibili per le shield SPI. Sono disponibili anche D0 e D1, se volete collegare un’interfaccia RS-232 e dimenticarvi dell’USB. A4 e A5 sono disponibili per applicazioni I2C. Adesso che abbiamo uno schema, possiamo assemblare l’elenco completo delle parti, mostrato nella Tabella 10-2. Tabella 10-2 - L’elenco delle parti della GreenShield.
Quantità
Tipo
Descrizione
2
SRD-05VDC-SL-C
1
DHT22
1
Generico
Sensore LDR
1
SainSmart
Sonda dell’umidità del suolo
6
3 mm
1
LM358N
1
ULN2003A
6
1 kohm, 1/8 W
Resistenza
4
2,2 kohm, 1/8 W
Resistenza
2
3,3 kohm, 1/8 W
Resistenza
2
10K trim
2
0,1” (2,54 mm)
Morsettiera da 3 posizioni
2
0,1” (2,54 mm)
Morsettiera da 2 posizioni
2
0,1” (2,54 mm)
Socket header a 8 posizioni
2
0,1” (2,54 mm)
Socket header a 6 posizioni
1
Personalizzato
PCB della shield
Songle 5A relè Sensore di umidità/temperatura
LED Amplificatore operazionale IC driver
Potenziometro montato sulla PCB
Il software Il software della GreenShield si basa su tre funzioni principali: l’input del sensore, l’analisi dei comandi e la generazione dell’output e la mappatura delle funzioni dei relè. La prima funzione è responsabile di ottenere dati da ciascuno dei quattro input dei sensori (temperatura, umidità, umidità del suolo e livello di illuminazione dell’ambiente) e di salvarne i valori perché li possano utilizzare altre parti del software. Le funzioni di analisi dei comandi interpretano le stringhe di comando che provengono da un PC host e generano risposte utilizzando il protocollo comando-risposta descritto qui. Le funzioni di output controllano i relè basandosi sugli input dei sensori e sui limiti predefiniti dai vari comandi. Il protocollo comando-risposta utilizzato per le transazioni tra il computer e la GreenShield per Arduino è mostrato nella Tabella 10-3. Notate che la GreenShield risponde soltanto all’host e non inizierà mai una transazione per sua iniziativa. Tabella 10-3 - Il protocollo comando-risposta della GreenShield (tutti i comandi).
Comando
Risposta
Descrizione
AN:n:?
AN:n:val
GT:HMX
GT:HMX:val
Ottiene il valore max dell’umidità
GT:HMN
GT:HMN:val
Ottiene il valore min dell’umidità
GT:LMX
GT:LMX:val
Ottiene il valore max della luminosità
GT:LMN
GT:LMN:val
Ottiene il valore min dell’umidità
GT:MMX
GT:MMX:val
Ottiene il valore max dell’umidità del suolo
GT:MMN
GT:MMN:val
Ottiene il valore min dell’umidità del suolo
GT:TMX
GT:TMX:val
Ottiene il valore max della temperatura
GT:TMN
GT:TMN:val
Ottiene il valore min della temperatura
HM:?
HM:val
Restituisce l’umidità corrente
RY:n:?
RY:n:n
Restituisce lo status del relè n
RY:n:1
OK
Imposta il relè n su ON
RY:n:0
OK
Imposta il relè n su OFF
RY:A:1
OK
Imposta tutti i relè su ON
RY:A:0
OK
Imposta tutti i relè su OFF
RY:n:HMX
OK
Imposta il relè n su ON se umidità >= max
RY:n:HMN
OK
Imposta il relè n su ON se umidità <= min
RY:n:LMX
OK
Imposta il relè n su ON se livello di luminosità >= max
Ottiene l’ingresso analogico n in raw DN
RY:n:LMN
OK
RY:n:MMX
OK
Imposta il relè n su ON se umidità del suolo >= max
RY:n:MMN
OK
Imposta il relè n su ON se umidità del suolo <= min
RY:n:TMX
OK
Imposta il relè n su ON se temperatura >= max
RY:n:TMN
OK
Imposta il relè n su ON se temperatura <= min
ST:HMX:val
OK
Imposta il valore max dell’umidità
ST:HMN:val
OK
Imposta il valore min dell’umidità
ST:LMX:val
OK
Imposta il valore max della luminosità
ST:LMN:val
OK
Imposta il valore min della luminosità
ST:MMX:val
OK
Imposta il valore max dell’umidità del suolo
ST:MMN:val
OK
Imposta il valore min dell’umidità del suolo
ST:TMX:val
OK
Imposta il valore max della temperatura
ST:TMN:val
OK
Imposta il valore min della temperatura
TM:?
TM:val
Imposta il relè n su ON se livello di luminosità <= min
Restituisce la temperatura corrente
Potete utilizzare lo strumento del terminale seriale integrato nell’IDE di Arduino, oppure potete uscire dall’IDE e collegarvi direttamente a una porta USB che utilizzi l’Arduino con la GreenShield. Questo approccio può essere utilizzato per creare un’applicazione di interfaccia utente per configurare la GreenShield e controllare il suo funzionamento. In pratica, l’idea è configurare il software della GreenShield su un Arduino e quindi lasciarlo attivo senza prestargli attenzione. I comandi per le query di stato Il software della GreenShield mette a disposizione quattro comandi per le query, che sono elencati nella Tabella 10-4. Questi comandi permettono a un host di controllo di ottenere lo stato corrente on/off di ciascuno dei due relè, l’ultimo valore letto dall’LDR o dall’ingresso analogico del sensore di umidità del suolo e gli ultimi valori di temperatura e umidità relativa ricavati dal sensore DHT22. Tabella 10-4 - I comandi per le query della GreenShield.
Comando
Risposta
Descrizione
RY:n:?
RS:n:n
AN:n:?
AN:n:val
Ottiene l’ingresso analogico n in raw DN
TM:?
TM:val
Restituisce l’ultima temperatura DHT22
Restituisce lo stato del relè n
HM:?
HM:val
Restituisce l’ultima umidità DHT22
I comandi per gestire i relè I relè della GreenShield possono essere controllati per mezzo di comandi software. Quattro comandi di controllo dei relè permettono a un singolo relè di essere impostato su on o su off, oppure entrambi i relè possono essere impostati su on o su off contemporaneamente. La Tabella 10-5 elenca i comandi per gestire i relè. Tabella 10-5 - I comandi per i relè della GreenShield.
Comando
Risposta
Descrizione
RY:n:1
OK
Imposta il relè n su ON
RY:n:0
OK
Imposta il relè n su OFF
RY:A:1
OK
Imposta tutti i relè su ON
RY:A:0
OK
Imposta tutti i relè su OFF
NOTA Notate che quando un relè viene impostato utilizzando uno di questi comandi, la mappatura precedente dei setpoint viene eliminata. Per utilizzare di nuovo un relè con un setpoint, deve essere inviato alla GreenShield uno dei comandi per i setpoint.
I comandi per mappare le azioni dei relè L’attivazione di ciascuno dei due relè può essere mappata su un punto specifico, minimo o massimo, delle condizioni di umidità, illuminazione, umidità del suolo o temperatura dell’ambiente. La Tabella 10-6 elenca i comandi per i setpoint dei relè. Quando si mappa un’azione su un relè, il comando di mappatura più recente sovrascrive quelli precedenti. Tabella 10-6 - I comandi per i setpoint dei relè della GreenShield.
Comando
Risposta
Descrizione
RY:n:HMX
OK
Imposta il relè n su ON se umidità >= max
RY:n:HMN
OK
Imposta il relè n su ON se umidità <= min
RY:n:LMX
OK
Imposta il relè n su ON se livello dell’illuminazione >= max
RY:n:LMN
OK
Imposta il relè n su ON se livello dell’illuminazione <= min
RY:n:MMX
OK
Imposta il relè n su ON se umidità del suolo >= max
RY:n:MMN
OK
Imposta il relè n su ON se umidità del suolo =< min
RY:n:TMX
OK
Imposta il relè n su ON se temperatura >= max
RY:n:TMN
OK
Imposta il relè n su ON se temperatura <= min
I comandi per i setpoint I setpoint minimo e massimo si definiscono utilizzando i comandi ST, elencati nella Tabella 10-7. Il valore del setpoint può essere restituito al PC host di controllo utilizzando i comandi GT. I valori dei setpoint possono essere modificati in qualsiasi momento. Tabella 10-7 - I comandi per impostare i valori min/max della GreenShield.
Comando
Risposta
Descrizione
ST:HMX:val
OK
Imposta il valore massimo dell’umidità
ST:HMN:val
OK
Imposta il valore minimo dell’umidità
ST:LMX:val
OK
Imposta il valore massimo dell’illuminazione
ST:LMN:val
OK
Imposta il valore minimo dell’illuminazione
ST:MMX:val
OK
Imposta il valore massimo dell’umidità del suolo
ST:MMN:val
OK
Imposta il valore minimo dell’umidità del suolo
ST:TMX:val
OK
Imposta il valore massimo della temperatura
ST:TMN:val
OK
Imposta il valore minimo della temperatura
GT:HMX
GT:HMX:val
Ottiene il valore massimo dell’umidità
GT:HMN
GT:HMN:val
Ottiene il valore minimo dell’umidità
GT:LMX
GT:LMX:val
Ottiene il valore massimo dell’illuminazione
GT:LMN
GT:LMN:val
Ottiene il valore minimo dell’illuminazione
GT:MMX
GT:MMX:val
Ottiene il valore massimo dell’umidità del suolo
GT:MMN
GT:MMN:val
Ottiene il valore minimo dell’umidità del suolo
GT:TMX
GT:TMX:val
Ottiene il valore massimo della temperatura
GT:TMN
GT:TMN:val
Ottiene il valore minimo della temperatura
La mappatura delle funzioni dei relè associa un relè all’input di un sensore e una serie di condizioni di cambiamento di stato nella forma di limiti superiori e inferiori. Un relè può essere attivato se il valore di un sensore va al di sopra o al di sotto di un limite impostato dal sistema di controllo dell’host. L’associazione dei relè non è esclusiva, che significa che entrambi i relè possono essere assegnati allo stesso input di un sensore e alle stesse condizioni. Non avrebbe senso farlo, ma sarebbe possibile. Anche se la GreenShield attualmente è configurata per due relè, non ci sono limiti al
numero di relè che potrebbe utilizzare. Come si può vedere nella Tabella 10-1, i pin I2C (A4 e A5) sono disponibili e quindi si potrebbe utilizzare una shield d’espansione I/O digitale I2C per collegare ulteriori dispositivi ad Arduino.
Il prototipo Per creare il prototipo per questo progetto, io utilizzo una cosa che viene detta Duinokit e che è mostrata nella Figura 10-10. Questo oggetto intelligente è dotato di una serie di sensori, LED, interruttori e altri accessori oltre che di un Arduino Nano, tutto montato su una grande PCB con molti socket header. Ha anche una posizione per collegare una shield convenzionale (o una pila di shield). È come una versione moderna dei vecchi kit per progetti di elettronica all-in-one che in passato erano molto diffusi.
Figura 10-10 - Il Duinokit.
Un approccio altrettanto valido sarebbe assemblare tutti i componenti necessari di un kit di sensori e praticamente un Arduino qualsiasi, ma il Duinokit mantiene le cose pulite e ordinate e fornisce una comoda piattaforma di sviluppo da utilizzare per creare il software mentre si aspetta che siano pronte la PCB e alcune delle altre parti. Il Duinokit è disponibile su http://duinokit.com e su Amazon.com. Il Duinokit ha un sensore di temperatura/umidità DHT11, che è una versione più lenta e a risoluzione più bassa del DHT22 che si utilizzerà con la GreenShield. Dal punto di vista del software, il DHT11 e il DHT22 sono simili ma non identici. Il DHT22 utilizza una word di dati (stringa di bit) diversa da quella del DHT11 per adeguarsi alla maggiore precisione del sensore DHT22. L’LDR e il sensore di umidità del suolo utilizzano un amplificatore operazionale duale LM358, con una metà assegnata a ciascun input. Io ho collocato l’LM358 sulla
breadboard che non richiede saldature fornita sull’unica grande PCB del Duinokit. Questa forniva anche un posto dove montare le resistenze e i due potenziometri da 10K del Duinokit che servono da controlli per il trim dell’offser di input.
Il software del prototipo Il software sarà sviluppato nella forma di prototipo e nella forma finale. Il primo passaggio è creare un software da utilizzare sul prototipo Duinokit che leggerà gli input dei sensori, verificherà che i circuiti dell’amplificatore operazionale LM358 si comportino come previsto ed eseguirà alcuni test per determinare i limiti iniziali dell’intervallo degli input. Il passaggio successivo è lo sviluppo del software finale che supporterà il protocollo comando-risposta definito in “Il software” a pagina 377 e la mappatura delle funzioni dei relè. L’hardware vero e proprio della shield sarà utilizzato per sviluppare il software finale. Il software del prototipo deve poter leggere i dati provenienti dagli input analogici e dal sensore DHT11 integrato sulla scheda. Questo è quello che sarà utilizzato per testare il prototipo, quando si stabiliscono gli intervalli di input iniziali. L’output appare nella finestra del serial monitor fornita dall’IDE di Arduino. Il software per testare il prototipo fornito nell’Esempio 10-1 è contenuto nel file di un unico sketch di nome gs_proto.ino. Esempio 10-1 - Il software del prototipo dei sensori della GreenShield.
NOTA Le funzioni mostrate nell’Esempio 10-1 per varie conversioni di temperatura e valori di punto di rugiada in realtà non sono necessari per la Greenshield. Li ho inclusi in questi esempi per l’eventualità nella quale voleste utilizzarli.
La funzione setup() si limita a inizializzare e ad aprire l’I/O seriale, a impostare alcune modalità dei pin e a cancellare le variabili globali dei risultati correnti dei dati. Ogni volta che vengono chiamate le funzioni readDHT() e readAnalog(), ottengono i valori più recenti del DHT11 e degli input analogici e li inseriscono in queste variabili. Il ciclo principale legge gli input analogici e il DHT11, formatta i dati e scrive i valori correnti sul serial monitor USB. Non comunica con un computer host di controllo e non esegue la mappatura dei setpoint di nessun relè. Il suo scopo è ottenere e mostrare continuamente i dati dei sensori. Il prototipo utilizza una libreria open source per il DHT11. La versione finale utilizzerà una libreria personalizzata per il DHT22, che nel prototipo non è necessaria. La libreria DHT11 di George Hadjikyriacou, SimKard e Rob Tillaart è disponibile presso l’Arduino
Playground (http://bit.ly/apg-dht11). Le funzioni Fahrenheit(), Kelvin(), dewPoint() e dewPointFast() provengono dalla stessa fonte.
Testare il prototipo Utilizzando il Duinokit, possiamo testare le varie funzioni di input dei sensori della GreenShield e regolarne il funzionamento. Se ci fosse un problema con i circuiti (che sarà facile da risolvere, dal momento che sono molto semplici), questo sarebbe il momento di trovarlo e risolverlo. Cercare di risolvere un problema su una PCB dopo averla prodotta e caricata di parti può rivelarsi davvero frustrante e c’è sempre il rischio che qualcosa venga danneggiato durante il procedimento. Nel caso della GreenShield, dobbiamo verificare che i sensori funzionino correttamente, che il software riesca a ottenere valori sensibili per cose come il sensore di umidità del suolo e l’LDR e che il sensore di umidità/temperatura si comporti come previsto. Per farlo, utilizzeremo un po’ di sabbia asciutta, acqua, un termometro digitale affidabile, un frigorifero, un forno e una giornata di sole. La prima cosa da controllare è il sensore di umidità/temperatura. Utilizzando un termometro esterno (in questo caso io ho utilizzato un termometro digitale con il sensore sul terminale lungo), ho cominciato a leggere l’ambiente. Il passaggio successivo è stato mettere il Duinokit e il termometro in un frigorifero. Un piccolo PC portatile forniva l’alimentazione e mostrava la temperatura e il cavo USB era abbastanza sottile da permettere alla porta del frigorifero di chiudersi completamente. Infine, il Duinokit e il termometro sono stati collocati in un forno acceso e impostato su circa 140 °F (60 °C). Con tre datapoint possiamo generare una curva calibrazione approssimativa per compensare le variazioni del sensore di temperatura. Testare la risposta dell’umidità è leggermente più difficile, ma ottenere i risultati vicini alle estremità dell’intervallo utilizzabile non è troppo complicato. Un breve soggiorno nella sezione freezer del frigorifero esporrà il sensore a un’ambiente dall’umidità molto bassa. I freezer sono secchi perché l’umidità nell’aria si condensa sulle molle all’interno dello scompartimento. Questo è quello che provoca il fenomeno del “freezer burn”, a proposito, che si verifica quando il cibo non è sigillato correttamente prima di essere congelato. È anche il principio che sta dietro la liofilizzazione, anche se di solito questa avviene a temperature molto più basse (circa –112 °F o –80 °C) e in una condizione parzialmente di vuoto. Nel caso del freezer di una cucina, possiamo aspettarci di riscontrare un’umidità di circa il 5% o forse qualcosa in meno. SUGGERIMENTO Un altro metodo è la cosiddetta “prova del sale”. Questa tecnica utilizza sale saturato con acqua per stabilire un’umidità relativa costante in un ambiente ermetico. Potete leggere un modo per eseguire una calibrazione con il sale sulla wiki Ambient Weather (http://bit.ly/wiki-aw). Se scegliete di eseguire questa prova, dovete fare attenzione a non far cadere sale o acqua sui componenti dei circuiti. Questo potrebbe non risultare molto pratico con un oggetto grande come il Duinokit, ma può essere utilizzato con la Greenshield finale.
Una volta che abbiamo il risultato dell’umidità bassa, il passaggio successivo è bollire un po’ d’acqua sul fornello e utilizzare un piccolo ventilatore per dirigere il vapore sul sensore. Il flusso di aria che ne risulta non sarà completamente saturato, ma rientrerà in
un intervallo di umidità compreso tra l’80 e il 90%. Questi test verificano che il sensore funziona, ma in realtà non possiamo utilizzare i dati per nient’altro perché non abbiamo riferimenti con i quali confrontarli. Se per caso avete a disposizione un sensore di umidità preciso, vi conviene assolutamente utilizzarlo e creare una curva di calibrazione come quella che è stata creata per la temperatura. Testare il sensore di umidità del suolo implica utilizzare un po’ di sabbia pulita e asciutta, una bilancia e un po’ d’acqua. Prima di tutto, prendete un bicchiere di vetro grande o una ciotola di ceramica. Entrambi andranno bene: sceglietene uno con una capacità di circa un litro. Non utilizzate una ciotola di metallo per questo test, perché la sonda di umidità del suolo utilizza un flusso di corrente e una ciotola di metallo potrebbe creare un risultato falso. Innanzitutto, pesate il contenitore e annotate questo valore, che vi servirà più avanti. Quindi, misurate circa 225 grammi di sabbia nel contenitore. Rimettetelo sulla bilancia e pesate di nuovo. Il peso della sabbia è quello che mostra la bilancia meno il peso del contenitore. Potete lasciare il contenitore sulla bilancia per il resto del test, se volete. Adesso inserite la sonde di umidità del suolo nella sabbia asciutta e annotate il risultato mostrato sull’output del serial monitor nell’IDE di Arduino. Togliete il sensore e aggiungere acqua finché il peso è di circa un quarto superiore rispetto al peso originale della sabbia più il peso del contenitore. Lasciatelo lì per un po’ per permettere all’acqua di filtrare nella sabbia. La sabbia deve notarsi umida al tocco, ma non deve risultare bagnata o fangosa. Reinserite il sensore e osservate l’output. Adesso la sabbia è saturata per circa il 50% e con questi due risultati, asciutto e umido, possiamo interpolare un punto intermedio, che chiameremo il punto 25%. Infine, c’è la fotocellula dell’LDR. La risposta delle fotocellula, in realtà, non è molto importante, ma conviene stabilire un punto per la luce bassa. Una giornata nuvolosa può rappresentare una buona occasione per usare la GreenShield per accendere qualche luce ausiliaria, oppure la si può utilizzare semplicemente per determinare la differenza tra giorno e notte. Tutto quello che è necessario per testare la fotocellula è una stanza interna a casa vostra (magari con le tende parzialmente chiuse e le luci spente), mentre fuori fa una bella giornata di sole. La luce solare diretta rappresenta il livello di illuminazione alla quale probabilmente sarà esposta la fotocellula, mentre la stanza interna a casa vostra è grossomodo l’equivalente del livello dell’illuminazione di una giornata grigia e nuvolosa. Dobbiamo registrare i dati del sensore di temperatura/umidità, dell’LDR e della sonda di umidità del suolo. Questi saranno i nostri valori iniziali quando configureremo la GreenShield per la prima volta e, dal momento che adesso sappiamo che cosa aspettarci, non dovremo tirare a indovinare i valori dei setpoint minimo e massimo adeguati dai quali partire.
Il software finale Il software del prototipo gestisce soltanto gli input dei sensori. La versione finale gestirà anche l’interfaccia di controllo dell’host e la mappatura delle funzioni dei setpoint dei
relè. Questo implica l’analisi dei comandi di input, oltre al salvataggio dei dati e al lookup. Non ci sono visualizzazione dell’output, a parte i quattro LED di stato per gli intervalli di umidità e temperatura, né input di controllo manuali. Una semplice interfaccia USB seriale si utilizza per le transazioni comando-risposta tra la GreenShield Arduino e un computer di controllo. Il volume del software fa sì che si debbano interpretare i comandi emessi dal PC host di controllo e poi che si applichi la mappatura dei setpoint ai relè.
L’organizzazione del codice sorgente La versione finale del codice sorgente della GreenShield è contenuta in diversi file sorgente o moduli. Quando l’IDE di Arduino apre il file principale, GreenShield.ino, apre anche gli altri file associati che si trovano nella stessa directory. I file secondari sono inseriti in “schede” dell’IDE, come mostra la Figura 10-11.
Figura 10-11 - L’IDE di Arduino con i file della GreenShield caricati.
La Tabella 10-8 elenca i file della serie GreenShield. Due file sono condivisi da tutti i moduli sorgente. Si tratta di gs.h e gs_gv.h. Le variabili globali definite in gs_gv.cpp, che altrimenti si troverebbero all’inizio di uno sketch convenzionale, sono compilati separatamente e condivisi come necessario tra gli altri moduli.
Tabella 10-8 - I moduli del codice sorgente della GreenShield.
Modulo
Funzione
GreenShield.ino
Modulo principale che contiene setup() e loop()
gs_gv.cpp
Variabili globali
gs_gv.h
File include
gs.h
Definizioni delle costanti (dichiarazioni #define)
gs_mapping.cpp
Mappatura delle funzioni
gs_mapping.h
File include
gs_parse.cpp
Analisi dei comandi
gs_parse.h
File include
gs_send.cpp
Funzioni di invio dei dati (all’host)
gs_send.h
File include
Organizzare un progetto in questo modo, rende più facile concentrarsi soltanto su una sezione alla volta senza dover cercare in tutte le righe del codice sorgente. Una volta che la sezione principale è fatta, si possono apportare modifiche negli altri moduli senza interferire con il codice finito. Questo approccio aiuta anche a pensare al software da un punto di vista modulare e questo a sua volta diventa più facile da capire e più facile da mantenere.
La descrizione del software La Figura 10-12 mostra il diagramma di flusso del ciclo principale del software. La funzione loop() comincia con il blocco “Start” e continua finché Arduino non viene spento. Notate che ci sono tre sezioni funzionali principali: input dei comandi ed elaborazione delle risposte, acquisizione dei dati e test dei setpoint minimo/massimo. Notate inoltre che il blocco etichettato come “Setpoint Test” è un’istanza di quattro blocchi, uno per ciascuna coppia di setpoin min/max. Per mantenere le dimensioni del diagramma entro i limiti del ragionevole, viene mostrata soltanto una sezione di test.
Figura 10-12 - Il diagramma di flusso della GreenShield.
Il file sorgente GreenShield.ino, mostrato nell’Esempio 10-2, contiene le funzioni setup() e loop(). Il software della GreenShield completo si trova su GitHub (https://github.com/ardnut). Esempio 10-2 - Il file sorgente principale della GreenShield.
L’IDE di Arduino si basa sulle dichiarazioni #include per determinare quali moduli del codice impostare. Anche se al livello più alto non viene utilizzato direttamente dal modulo un file sorgente, può comunque essere incluso. Il file delle definizioni globali gs.h, mostrato nell’Esempio 10-3, definisce una serie di costanti utilizzate dai moduli sorgente della GreenShield. Le dichiarazioni #define producono un oggetto compilato più piccolo, come si mostra in “Le costanti” a pagina 114. Esempio 10-3 - Le definizioni globali della GreenShield.
Nell’Esempio 10-3, la definizione di MAXRY è 2. Questo può essere un valore più grande se è presente l’hardware per supportare ulteriori relè e gli output non devono essere relè. Il file include gs_mapping.h, mostrato nell’Esempio 10-4, dichiara le funzioni per leggere il DHT22 e gli input analogici, per impostare lo stato on/off state di ciascun relè (o di tutti i relè), per controllare i LED di stato e per eseguire una scansione delle condizioni di risposta che controlleranno i relè nella funzione ScanMap(). Esempio 10-4 - Le funzioni di mappatura della GreenShield.
La funzione ScanMap() in gs_mapping.cpp, mostrata nell’Esempio 10-5, viene eseguita in ciascun ciclo della funzione loop() nel file sorgente principale GreenShield.ino. Valuta gli input analogici confrontandoli con una serie di limiti configurabili e attiva oppure disattiva i relè basandosi su queste condizioni. Esempio 10-5 - Lo scanner della mappa di funzioni della GreenShield.
Il modulo sorgente gs_parse.cpp contiene una funzione principale, ParseCmd() e un paio di funzioni di supporto (CntInt() e SendErr()). L’Esempio 10-6 mostra i contenuti di gs_parse.h. Esempio 10-6 - Il file include con il modulo per il parsing della GreenShield.
Per adesso, la funzione ParseCmd() è una delle funzioni più lunghe del codice della GreenShield. Utilizza un parser condizionale, veloce e discendente del tipo ad albero per
determinare il tipo di comando in arrivo e quindi estrae il codice della sottofunzione e tutti i parametri. Questa funzione esegue anche qualsiasi comando immediato come attivare o disattivare relè, restituire informazioni sullo stato dei relè e acquisire e restituire dati analogici all’host di controllo o a un utente. L’esecuzione dei comandi immediati avviene presso gli endpoint della struttura ad albero discendente.
La produzione Fornire una descrizione passo a passo di come si creano schemi e schede a circuito stampato va oltre l’ambito di questo libro. Questa è una descrizione di alto livello dei passaggi necessari per passare dallo schema al layout della PCB alla PCB finita. Per i dettagli di basso livello, vi consiglio di leggere alcuni dei testi elencati nell’Appendice D. Cercando su Google “CadSoft Eagle”, troverete numerosi tutorial. Vi consiglio quelli di SparkFun, Adafruit e, naturalmente, CadSoft (http://www.cadsoftusa.com/). La versione di Eagle dello schema della Greenshield è mostrata nella Figura 10-13. Notate il blocco etichettato “ARDUINO_R3_SHIELD”. Questo viene dalla libreria delle parti di SparkFun per Eagle ed è pensato specificamente per creare shield. È molto più comodo che calcolare il posizionamento degli header dei pin manualmente più tardi o durante la fase del layout della PCB.
Figura 10-13 - Lo schema della GreenShield (versione di Eagle).
L’editor di schemi di Eagle, come tutti gli strumenti simili, richiede un po’ di tempo per poter essere utilizzato. Non è sempre ovvio e intuitivo. Normalmente, per creare disegni (compresi schemi) con una qualità sufficiente per la pubblicazione io utilizzo uno strumento diverso, ma per creare una PCB è utile disporre di un editor di schemi e di
uno strumento per il layout delle PCB che possa condividere dati. Per vedere la differenza, potete confrontare la Figura 10-13 con la Figura 10-9. Lo strumento Eagle e lo strumento di design Fritzing, utilizzato nel progetto Switchinator, sono in grado di mantenere sincronizzati schemi e layout, mentre uno strumento grafico per disegni e illustrazioni non ha questa capacità. Quando create uno schema, dovete assicurarvi di aver selezionato la parte corretta. Per esempio, il simbolo delle resistenze è lo stesso, a prescindere dal fatto che si tratti di un componente 0805 SMD (a montaggio superficiale) o di un componente through-hole da 1/4 di watt. A volte, trovare la parte giusta nella libreria dell’editor di schemi può risultare difficile. Con Eagle, potete utilizzare caratteri wildcard per effettuare ricerche nella libreria. Quando cercavo la parte ULN2003AD per la GreenShield, ho digitato *2003* e ho trovato quello che stavo cercando nella categoria uln-udn. A volte è necessario andare online e cercare una parte che qualcuno può aver già creato. SparkFun, Adafruit e altri hanno creato vaste librerie di parti che si possono scaricare gratuitamente. Una volta che lo schema è completo, si può generare la PCB. Inizialmente, il layout della PCB non è altro che un mucchio di parti e di sottili linee di connessione (“fili volanti”, come vengono detti a volte) che formano un “nido di topo” di fili. Il nido di topo mostra le connessioni da punto a punto come definito nell’elenco creato a partire dallo schema. Il primo passaggio è spostare tutte le parti nell’area della PCB e quindi organizzarle. Gli obiettivi principali quando si sistemano le parti sono collocare i connettori nelle posizioni desiderate, raggruppare le parti in base alla funzione e ridurre al minimo il numero di occorrenze di linee del nido di topo che si incrociano, se necessario ruotando le parti. Una volta che questo passaggio iniziale è completo, è molto più facile cominciare a creare le tracce che collegheranno le parti. Potete scegliere di dirigere ciascuna traccia a mano, utilizzando i fili del nido di topo come guida, oppure, se vi sentite fortunati, potete lasciare che se ne occupi un autorouter. Eagle non è dotato di un autorouter, ma io generalmente non lo utilizzo. L’autorouting di solito è un processo iterativo per cercare di ottenere un buon layout, spostando e ruotando le parti e poi provandoci di nuovo. Dopo un po’, nel caso di alcuni design, diventa evidente che si fa prima a farlo manualmente. In Eagle, non dovete posizionare manualmente una via (una via trasferisce una traccia da un lato della PCB all’altra per mezzo di un foro placcato, da qui il nome). Se dovete passare dalla parte superiore della PCB a quella inferiore (o viceversa), non dovete fare altro che cambiare da un alto all’altro con il livello di selezione abbassato che si trova sul lato sinistro della barra di strumenti per disegnare le tracce. Eagle aggiunge automaticamente una via nella posizione e inverte il routing delle tracce sul lato selezionato della PCB. Il layout della PCB è mostrato nella Figura 10-14. Il lato superiore (componente) è rossiccio e quello inferiore (saldatura) è blu. Se per caso disponete della versione stampata di questo libro, potete vedere che le tracce superiori sono grigie chiare e che quelle inferiori sono grigie scure. I contorni dei componenti sono grigio chiaro.
Figura 10-14 - Il layout della PCB della GreenShield.
I file generati dallo strumento Eagle CAM (Computer Aided Manufacturing), detti file “Gerber”, vengono utilizzati da chi produce PCB per creare le PCB vere e proprie. Per caricare e visualizzare i file Gerber nella fase dell’ultimo controllo, io ho utilizzato lo strumento Gerbv, che fa parte del pacchetto gEDA. Nella Figura 10-15 è mostrata una cattura della schermata di Gerbv.
Figura 10-15 - Il visore di file Gerber di Gerbv.
NOTA Per poter approfittare del servizio a basso costo per prototipare PCB, i contorni della scheda della GreenShield sono stati squadrati per renderla un rettangolo. Può sembrare un po’ strano, pero non ha conseguenze sul suo funzionamento. Nelle foto non lo vedrete, ma originariamente il layout è stato fatto utilizzando i contorni della shield di Arduino. Convertire gli angoli in angoli retti ha richiesto circa 5 minuti ed è stato fatto subito prima che il layout fosse inviato per la sua produzione. Se fosse stato davvero importante, avrei potuto pagare un prezzo molto più alto per gli angoli arrotondati e il lavoro di ritaglio, oppure potrei aver utilizzato il mio router e aver fatto da solo. Ho scelto di lasciarla semplicemente in forma rettangolare.
Ricevere la PCB finita richiede circa da 7 a 10 giorni. La Figura 10-16 mostra la PCB come è arrivata dal produttore.
Figura 10-16 - La PCB della GreenShield finita.
Dopo che le parti vengono saldate sulla PCB, conviene sempre dedicare qualche minuto a esaminarne entrambi i lati per ispezionare le saldature e i cortocircuiti (detti “ponti”) tra le piazzole e le tracce. Per farlo, io ho utilizzato una lente di ingrandimento standard da gioielliere. La Figura 10-17 mostra come si presenta una GreenShield completamente assemblata. Potete notare che per le connessioni con un Arduino sottostante o con un’altra shield ho utilizzato header impilati. Anche se inserire un’altra shield sulla GreenShield può risultare scomodo (e io lo sconsiglio), volevo disporre di alcuni punti di test e I/O rapidamente accessibili.
Figura 10-17 - La PCB della GreenShield riempita di componenti e pronta per l’uso.
Il collaudo finale Le parti a montaggio superficiale presentano la loro serie unica di problemi potenziali. Prima di fornire l’alimentazione alla GreenShield, dobbiamo eseguire alcuni veloci controlli per assicurarci che tutto sia collegato correttamente e che non ci siano cortocircuiti sulla PCB: Ispezione visiva Esaminiamo attentamente i componenti delle PCB cercando ponti di saldature (saldature che collegano due piazzole o tra una piazzola e una traccia). Esaminiamo le resistenze per vedere se qualcuna ha un’estremità che può essere sollevata sulla piazzola e non collegata. Questo può accadere quando si utilizzano saldature regolari e filo per saldare (io ho utilizzato pasta per saldare e uno strumento a rifusione SMD ad aria calda). Guardiamo le piazzole degli IC (U1 e IC1) per assicurarci che non ci siano ponti di saldatura tra loro. Posizionamento dei componenti Ci sono nove parti che possono essere montate accidentalmente al contrario. Queste sono due IC, i LED e il modulo sensore DHT22. L’IC dell’amplificatore operazionale può avere un segno o un puntino che indica il pin 1, ma alcuni package presentano un bordo smussato. Oltre a diverse lunghezze dei terminali, di solito i LED hanno una piccola area piatta accanto alla connessione del catodo (–). Cortocircuiti
Utilizzando un DMM, preferibilmente con una funzione di test di continuità (la modalità beeper), controlliamo ciascuna coppia di pin sull’amplificatore operazionale LM358 (IC1) per evitare cortocircuiti. Nessuno dei pin deve fare cortocircuito con un altro pin. Adesso controlliamo che la VCC sul pin 8 di IC1 sia legato ai 5 V sull’header di pin. Inoltre, controlliamo che il pin 4 sia legato a uno dei pin della messa a terra sull’header di pin. Ripetiamo questa procedura per il driver ULN2003A (U1). Nessuno dei pin di input o di output deve fare cortocircuito, il pin 8 deve essere legato alla messa a terra e il pin 9 deve essere collegato all’alimentazione da 5 V. Sicurezza elettrica Prima di collegare la GreenShield a una scheda Arduino, utilizziamo un DMM per misurare la resistenza tra i pin +5 V e messa a terra sull’header di pin. Dovremmo vedere un valore di non meno di 30 kohm, probabilmente più alto. Se otteniamo un risultato pari a di zero, significa che c’è un cortocircuito da qualche parte, che deve essere trovato ed eliminato prima di cercare di fornire alimentazione alla GreenShield. Se la GreenShield appare accettabile dal punto di vista elettrico, possiamo montarla su un Arduino e fornirle alimentazione. All’inizio, non deve essere attivo nessuno dei LED della GreenShield (a meno che non ci sia qualche software già caricato sull’AVR di Arduino che stia controllando i pin I/O digitali). I test funzionali includono quattro passaggi fondamentali: Test funzionale iniziale La prima parte dei test funzionali richiede che si esegua nuovamente lo stesso test che si era svolto con il prototipo per testare gli input analogici e il DHT22. Carichiamo la versione del prototipo del software su Arduino e apriamo la finestra del serial monitor dell’IDE. Se tutto funziona correttamente, dovreste vedere una visualizzazione che si ripete con la temperatura, l’umidità e gli input analogici. Test degli input analogici Colleghiamo una resistenza da 470 ohm agli input dell’LDR. Mentre osserviamo l’output continuo, regoliamo R12 finché il valore non raggiunge lo zero. Questo dimostra che questa parte del circuito sta funzionando correttamente. Adesso ripetiamo il tutto con R8 per il sensore di umidità del suolo. Test del DHT22 I risultati di output provenienti dal DHT22 devono essere quelli che vi aspettate in base alla temperatura e all’umidità locali. Possiamo utilizzare una fonte di aria calda (un asciugacapelli, per esempio) per applicare aria tiepida (non calda!) sul DHT22 e osservare la sua risposta. Test funzionale del software
Adesso carichiamo la versione completa del software della GreenShield. Per questi test possiamo utilizzare la finestra del serial monitor dell’IDE di Arduino. Questa non è una serie di test completa, dal momento che ne abbiamo già eseguiti alcuni prima con il prototipo. Con tutto il software della GreenShield caricato, dobbiamo vedere la parola “OK” quando parte. La GreenShield non fornisce un prompt. Digitiamo il comando RY:0:? e la risposta deve essere RY:0:0. Adesso digitiamo il comando RY:0:1. Il relè deve fare un clic e il LED associato deve illuminarsi. Utilizzando il comando RY: 0:? adesso otteniamo RY:0:1. Dovremmo provare anche il resto dei comandi. Possiamo testare i limiti analogici facendo cortocircuito oppure aprendo gli input analogici. Il DHT22 è indipendente e quindi non dobbiamo farci molto, ma possiamo impostarne i limiti molto vicini e utilizzare una fonte di aria calda e un po’ di vapore di una pentola di acqua bollente per verificare che i limiti di temperatura e umidità funzionaino come sperato.
Ammissione sui test Quando ho assemblato la prima scheda GreenShield, non riuscivo a trovare un contenitore per il nuovo relè Songle da 5 V che avevo acquistato. Ho cercato ovunque. Quindi ho preso un paio di relè blu da una scatola e li ho saldati sulla PCB. Erano della forma giusta, del colore giusto e della marca giusta. Ma la tensione della bobina non era quella giusta: 12 V DC invece di 5 V DC. Non capivo perché i relè non rispondevano ai comandi del software, finché non ho guardato cosa c’era scritto sui due relè e ho scoperto che cosa avevo fatto. Nel frattempo, avevo trovato i relè da 5 V (erano giusto dove li avevo lasciati, ovviamente). Poco dopo, ho tolto i relè da 12 V, ho installato le parti corrette da 5 V e i comandi di controllo dei relè e la mappatura delle funzioni hanno funzionano come previsto. Morale della favola: esaminare sempre le parti che si stanno installando, prima di saldarle sulla PCB.
Il funzionamento Dal punto di vista fisico, la GreenShield è semplice, ma dal punto di vista funzionale può essere complessa nei termini di come si integra nell’ambiente per il quale è pensata. I due principali input variabili, il livello dell’illuminazione e quello dell’umidità del suolo, devono essere calibrati per una specifica serie di condizioni. L’intervallo dell’LDR e della sonda di umidità del suolo determina come si impostano i punti intermedi utilizzando i potenziometri dei trimmer. Non tutti gli LDR sono uguali e ci sono differenze tra una sonda di umidità del suolo formata soltanto da un paio di sonde e una che include un transistor. Ci sono due approcci di base per regolare la GreenShield: (1) calibrare la GreenShield per intervalli noti utilizzando riferimenti di qualche tipo, oppure (2) regolare la GreenShield per un ambiente specifico utilizzando una valutazione soggettiva (per esempio: il suolo è abbastanza umido?). L’approccio calibrato permette di specificare degli intervalli in base a dati puri e, se si conosce l’umidità del suolo ideale per esempio, per i pomodori, si può utilizzare questi valore una volta che si è eseguita la calibrazione e calcolato come i risultati dell’ADC
corrispondono all’umidità del suolo. “Testare il prototipo” a pagina 386 ha descritto le procedure di base necessarie per calibrare la GreenShield per i livelli di umidità del suolo e di illuminazione, ma come riferimento si può anche utilizzare una cara attrezzatura da laboratorio. L’approccio soggettivo è molto più facile e, dal momento che l’obiettivo principale è evitare di uccidere le proprie piante, probabilmente diventa efficace soltanto dopo qualche tentativo. Si possono regolare i potenziometri dei trimmer in modo che si adattino ai valori massimo e minimo di una valutazione soggettiva di quello che sarebbe accettabile. Io vi suggerisco di fare qualche esperimento, per vedere quale approccio è più adatto per la vostra applicazione. Vi suggerisco anche di prendervi il tempo necessario per registrare i dati provenienti dalla GreenShield e costruire alcuni profili che potete studiare per ottenere le risposte migliori in base alla vostra situazione.
Prossimi passaggi La GreenShield è piuttosto essenziale, a dire il vero, ma presenta una grande potenzialità. Potete utilizzarla con una shield Bluetooth o addirittura con una shield Ethernet e controllare in remoto le condizioni del suolo del vostro vaso di piante preferite, di pomodori e orchidee in una serra, di un piccolo orto esterno, oppure di un giardino in una colonia su Marte. Se collegate una normale valvola per sistemi di irrigazione 24VAC a uno dei relè, potete rendere l’irrigazione automatica. Potete utilizzare l’altro relè per attivare un ventilatore in una serra che produca un po’ di fresco, oppure collegarlo a una stufa per mantenerla calda durante l’inverno. E, naturalmente, potete sempre aggiungere un altro relè o due con un modulo relè esterno come quello descritto nel Capitolo 9. Potete utilizzare anche un shield microSD per montare la GreenShield su un albero in un bosco e registrare dati per un periodo lungo (anche un pannello solare per mantenerla attiva sarebbe una buona idea). Se vi aggiungete una shield WiFi o GSM, potete lasciare diverse GreenShield in vari punti di una azienda agricola relativamente grande per tenere sotto controllo le condizioni del suolo. SUGGERIMENTO Attualmente, il software della GreenShield non salva i valori dei setpoint quando Arduino perde l’alimentazione. Un modo per aggirare questo problema è utilizzare la EEPROM dell’IC dell’AVR. Trovate una panoramica della libreria EEPROM nel Capitolo 7.
Design personalizzati compatibili con Arduino Costruire una PCB compatibile con l’hardware di Arduino è facile. In effetti, i ragazzi di Arduino forniscono perfino i file degli schemi e del layout della PCB da scaricare. Non forniscono le maschere delle serigrafie, tuttavia, dal momento che sono protette da copyright di Arduino.cc e non sono cedute sotto licenza aperta. Per la vostra scheda,
dovrete creare le vostre immagini personalizzate. Anche se gran parte di quello di cui avrete bisogno per costruire una copia di un Arduino o di una shield è facile da trovare, in realtà non risulta molto economico clonare il design di un Arduino esistente (che sia una shield o una scheda MCU). A meno che non possediate o abbiate accesso a un impianto di produzione di PCB e vi servano centinaia o addirittura migliaia, di unità di un particolare tipo di scheda, è difficile che riusciate a trovare qualcosa di già pronto a un prezzo unitario molto inferiore di quanto non vi costerebbe costruirvele da soli. L’approccio personalizzato ha senso se i fattori di forma delle PCB esistenti e disponibili non vanno bene per voi. Magari volete integrare un Arduino in un sistema più grande, oppure inserire una MCU AVR in una posizione unica e limitata come un aereo privo di pilota o un robot. Se questo è il vostro caso, potete decidere di creare una PCB compatibile con il software. La vostra scheda non deve avere lo stesso aspetto di un Arduino e non c’è motivo per cui debba essere compatibile con shield esistenti, a meno che, naturalmente, non vogliate utilizzarla con una shield di un’altra marca. Come abbiamo visto nel Capitolo 1, un dispositivo può essere compatibile con il software di Arduino senza essere compatibile con il suo hardware. Tutto quello che serve è un processore AVR adatto, il firmware del bootloader e le librerie di runtime di Arduino. Perfino il firmware del bootloader è facoltativo. In questo paragrafo, progetteremo e costruiremo un controller di alimentazione DC basato su AVR adatto per essere utilizzato con robusti relè, LED ad alto consumo e motori AC o DC.
Programmare un design personalizzato Se desiderate utilizzare il bootloader di Arduino con un microcontroller AVR nuovo di zecca, dovete installare il bootloader nella memoria flash integrata nel chip. Fatto questo, potete trattare la vostra scheda personalizzata come se fosse un Arduino qualsiasi. Gli strumenti e le procedure necessarie per caricare il codice eseguibile su una MCU AVR sono descritte in “Caricare codice eseguibile sull’AVR” a pagina 150 nel Capitolo 6. In alternativa a installarvi il firmware del bootloader da soli, molti rivenditori propongono dispositivi AVR con il bootloader di Arduino già installato. Potete cercare su Adafruit (https://www.adafruit.com/) e SparkFun (https://www.sparkfun.com/)gli IC ATmega328 con il firmware del bootloader di Arduino preinstallato. Digitando “ATmega328 with Arduino bootloader” nel campo di ricerca di Amazon.com o di eBay, trovate numerosi elenchi. Una volta installato il bootloader, potete utilizzare l’adattatore USB-seriale o perfino un’interfaccia seriale standard con un modulo RS-232 adatto come quello mostrato nella Figura 10-26, oppure un breakout USB-seriale come il dispositivo di SparkFun mostrato nella Figura 6-8. Nel caso di alcuni progetti, come lo Switchinator che vedremo nel prossimo paragrafo, l’interfaccia seriale non è un’opzione per programmare la MCU se è già in uso, oppure se non è utilizzato il bootloader. Questo significa che dovrete utilizzare un programmatore ISP (ICSP) come l’Atmel-ICE oppure l’USBtinyISP, entrambi i quali sono descritti nel Capitolo 6.
Lo Switchinator Il dispositivo descritto qui, che io chiamo Switchinator (in mancanza di una denominazione migliore), è un interruttore DC controllato in remoto da 14 canali con 4 canali di input analogico. Questa versione iniziale utilizza un’interfaccia RS-232 e un semplice protocollo comando-risposta. Una possibile modifica per una versione futura potrebbe essere utilizzare un’interfaccia RS-485 anziché la RS-232.
La definizione e la pianificazione Lo Switchinator è una PCB indipendente che può utilizzare una semplice MCU ATmega328 oppure ATmega328p senza il bootloader di Arduino. Può utilizzare anche una MCU con il firmware del bootloader installato con un programmatore seriale oppure un convertitore USB-seriale. Per la programmazione, io ho scelto di utilizzare l’IDE di Arduino per compilare un USBtinyISP di Adafruit. Trovate maggiori informazioni sulla programmazione della MCU nel Capitolo 6. Ecco l’hardware: •
ATmega328
•
16 MHz sorgente di clock a cristalli
•
Interfaccia di programmazione ICSP
•
Alimentazione 5 V DC integrata (input da 9 a 12 V DC)
Input e output: •
4 input analogici
•
14 output discreti digitali
Controllo dell’interfaccia: •
Interfaccia host RS-232
•
Protocollo comando-risposta, gestita dall’host di controllo
•
Risultati analogici disponibili su richiesta
•
Output sostituito dall’host di controllo
Lo Switchinator fornisce 14 output discreti digitali e 4 input analogici e l’interfaccia SPI è disponibile per mezzo di una serie di pin ICSP. Gli output discreti digitali e gli input analogici sono terminati sul bordo della PCB utilizzando morsettiere a vite. Per la comunicazione tra la scheda e un computer che funga da host di controllo per mezzo dei pin D0 e D1 delle morsettiere della MCU si utilizza un’interfaccia RS-232. La PCB è un design al 100 per cento through-hole. Questo ne semplifica l’assemblaggio, al prezzo di una PCB più grande e di un layout della PCB potenzialmente più difficile. La dimensione della PCB non supererà la dimensione rettangolare di 100 mm per 140 mm. Su ciascun angolo della PCB si trovano dei fori di
montaggio. Gli output discreti digitali dello Switchinator possono essere utilizzati per gestire relè, come il tipo utilizzato dalla GreenShield, oppure per controllare fino a tre motori passopasso unipolari utilizzando un circuito di base come quello mostrato nella Figura 10-18.
Figura 10-18 - Un ULN2003A collegato come driver di un motore passo-passo.
Gli output digitali dello Switchinator possono inoltre gestire LED ad alto consumo, solenoidi o motori DC, come mostra la Figura 10-19.
Figura 10-19 - Un driver per motori DC ULN2003A.
Per sviluppare la versione iniziale del software, utilizzeremo un semplice prototipo basato su un breadboard che non richiede saldature. Completeremo la versione finale sull’hardware finito. Per il design dell’hardware finale, per gli schemi e il layout della PCB utilizzerò Fritzing.
Il design Lo Switchinator è una singola PCB, di dimensioni 124 × 96 mm, con quattro fori di montaggio sugli angoli. La dimensione finale della scheda è maggiore di quella che
sarebbe altrimenti possibile con un design a montaggio superficiale (è anche maggiore rispetto ai limiti di dimensione impostati dalla versione gratuita dello strumento Eagle che abbiamo utilizzato per la GreenShield). Non presenta custodia né alimentazione, cosa che ne semplifica enormemente il design. Lo Switchinator è completamente autosufficiente e per funzionare richiede soltanto una fonte di alimentazione DC esterna.
Le funzionalità Lo Switchinator è un dispositivo di output digitale con qualche funzionalità di input analogico. Il suo scopo principale è quello di commutare carichi DC, sia induttivi sia non induttivi. Per decodificare gli input dei comandi e restituire dati di stato all’host di controllo, utilizza una MCU AVR ATmega328. Un ATmega328 è utilizzato principalmente come decodificatore di comandi per interfacciare gli I/O della PCB con un sistema host. Sebbene sia stato programmato per comportarsi come un dispositivo I/O, può essere programmato anche per eseguire funzioni autonome basate sugli input analogici. Utilizzando un sensore lineare di temperatura, come l’LM35, lo Switchinator può essere riprogrammato facilmente in modo che funga da controller per camere di prove ambientali o per camere di indurimento di resina epossidica. Dal punto di vista dei circuiti, lo Switchinator è composto da tre sezioni principali: la MCU, gli I/O digitali e l’alimentazione. La Figura 10-20 mostra un diagramma a blocchi dello Switchinator.
Figura 10-20 - Un diagramma a blocchi dello Switchinator.
Gli output discreti digitali sono gestiti da IC ULN2003A. Sono forniti inoltre quattro input
analogici e il riferimento analogico e le tensioni AVCC possono essere forniti dall’alimentatore interno integrato sulla scheda oppure esternamente. Per selezionare le sorgenti di tensione analogica, si utilizzano jumper. Per monitorare e controllare lo Switchinator, si utilizza un semplice protocollo comandorisposta comprensibile per gli umani.
L’hardware Lo Switchinator avrà 14 output digitali, ciascuno collegato agli output Darlington di una coppia di IC driver ULN2003A. I driver ULN2003A sono dotati di sette canali per IC e ciascun canale degli ULN2003A può gestire fino a 300 mA o, in alcuni casi, di più. Per gestire le parti degli ULN2003A, si utilizzerà un microchip MCP23017 I2C che espande gli I/O digitali, soprattutto per evitare di utilizzate tutti i pin I/O digitali disponibili della MCU AVR. Due dei pin I/O digitali dell’AVR si utilizzano per l’interfaccia seriale e due dei pin analogici sono utilizzati per l’interfaccia I2C con l’IC MCP23017. I pin I/O digitali non collegati non vengono utilizzati, ma rimangono disponibili per future espansioni. Un’interfaccia RS-232 viene implementata utilizzando un IC ricetrasmittente MAX232 TTL-to-RS232. L’interfaccia seriale servirà a comunicare con il sistema host che si comporterà come controller master. Il controller master può essere un PC, un Arduino, oppure un controller programmabile di un qualche tipo con un’interfaccia RS-232. Per l’interfaccia seriale si utilizza un connettore DB-9. Questa non è un’implementazione completa di RS-232, ma soltanto dei segnali RxD e TxD. Lo Switchinator non è dotato di un connettore USB. Gli output digitali e gli input analogici sono terminati utilizzando una morsettiera a vite da 3,5 mm (0,138 pollici, 138 mil). Inoltre, due jumper consentono input di tensione di V+ analogico e di riferimento analogico forniti esternamente per mezzo di una morsettiera. Per l’alimentazione DC si utilizza un connettore standard montato sulla PCB del tipo a cilindro. L’alimentazione può variare da 6 a 12 V DC (9 V è ottimale). Per la regolazione della tensione a 5 V sulla PCB, si utilizza un 7805 in un package TO-220. La Figura 1021 mostra lo schema creato da Fritzing.
Figura 10-21 - Schema dello Switchinator.
NOTA La notazione dello schema utilizzata nella Figura 10-21 illustra che cosa succede quando le parti di una libreria di strumenti non seguono le stesse convenzioni di dimensioni e distanza. Questo è un problema che si riscontra spesso con gli strumenti open source, perché non tutte le parti possono aver seguito le stesse regole. Questo non significa che non funzionerà: soltanto che sembrerà strano.
L’expander degli I/O digitali MCP23017 L’MCP23017 con un’interfaccia I2C e suo fratello, l’MCP23S17 con un’interfaccia SPI, sono dispositivi controllati da registri per dirigere segnali binari tra un dispositivo master e fino a 16 input o output digitali discreti. La spiegazione del funzionamento interno dell’MCP23017 vale anche per l’MCP23S17. Questi dispositivi si utilizzano nelle shield di espansione I/O come quelle descritte nel Capitolo 8 e rappresentano un modo semplice di estendere le funzionalità I/O di una MCU. Utilizzando i pin di indirizzamento, è possibile collegare fino a 8 IC MCP23017 a una MCU AVR, ottenendo 128 canali di I/O digitali discreti. Il comportamento dell’MCP232017 è definito dal contenuto di una serie di registri di controllo e di dati. Il master può leggere o impostare i valori dei registri in qualsiasi momento, per mezzo dell’interfaccia I2C o SPI. La Figura 10-22 mostra un diagramma a blocchi dell’MCP23017. L’MCP23S17 è identico, eccetto che per l’incorporazione di un’interfaccia SPI al posto dell’interfaccia I2C.
Figura 10-22 - L’expander I/O MCP23017. L’MCP23017 ha 22 registri interni organizzati in 11 coppie con un registro A per la porta GPIO con etichetta A e un registro B per la porta B. La direzione delle porte (input o output) è impostata con l’apposito registro IODIRA o IODIRB. La polarità delle porte (active high o active low) è impostata con i registri IPOLA o IPOLB. GPINTENA e GPINTENB attivano la generazione degli interrupt. GPPUA e GPPUB attivano i pull-up interni. Il segnale sui pin della porta A o della porta B sono letti dati registri GPIOA o GPIOB. I registri OLATA e OLATB restituiscono gli stati dei blocchi di uscita interni, che vengono impostati quando una porta si trova nella modalità di output e i dati vengono scritti nei registri GPIOA o GPIOB. La Tabella 10-9 elenca la serie completa di registri. Notate che gli indirizzi dei registri sono esadecimali (Addr = indirizzo nello spazio dei registri dell’MCP23017) e POR/RST si traduce come reset power-on o reset esterno.
Tabella 10-9 - I registri di controllo dell’MCP23017 (IOCON.BANK = 0).
L’MCP23017 ha altre funzionalità, delle quali tutte possono rivelarsi utili per determinate applicazioni. Per applicazioni I/O digitali semplici, in realtà l’unica cosa che deve succedere è che si devono leggere o scrivere i registri GPIO. Trovate maggiori dettagli sui registri nella scheda tecnica dell’MCP23017/MCP23S17 (http://bit.ly/micro-mcp). Un altro aspetto dell’MCP23017 è come comunicare con esso. Per accedere ai registri interni, si utilizza un protocollo a due fasi. Il primo passaggio è inviare un byte di controllo e l’indirizzo del registro al quale si desidera accedere. Il secondo passaggio è leggere o scrivere il registro. Il registro selezionato per ultimo rimarrà attivo finché non viene selezionato un nuovo registro con una coppia di byte di controllo–indirizzo del registro. Il byte di controllo è l’indirizzo a 7 bit dell’MCP23017 con un bit R/W (read/write, lettura/scrittura). In un sistema con un unico IC, questo deve essere sempre 0 per i bit A0, A1 e A2 con il sesto bit predefinito come 1, che produce valori in byte di 0x20 se si tratta di un’operazione di scrittura e 0x21 se si stanno leggendo dati (il bit lettura/scrittura è l’ultimo bit significativo del byte di controllo). Esistono diverse librerie per interagire con i dispositivi MCP23017 e MCP23S17 e scrivere una libreria personalizzata non è difficile. La porzione di codice mostrata nell’Esempio 10-7 mostra come indirizzarsi al registri di direzione I/O e al registro GPIOA come input utilizzando l’interfaccia I2C e la libreria Wire. Esempio 10-7 - Accedere ai registri IODIRA e GPIOA dell’MCP23017.
Poiché al momento dell’accensione o dopo un reset le porte I/O GP sono configurate come input per impostazione predefinita (vedere la Tabella 10-9), il primo passaggio può essere saltato. Per configurare la porta come output, i bit IODIRA devono essere impostati su 0. Questo è mostrato nella porzione di codice dell’Esempio 10-8. Esempio 10-8 - Scrivere dati sulla porta di output.
L’interfaccia SPI dell’MCP23S17 si comporta in un modo simile e volendo si possono utilizzare perfino i pin dell’indirizzo. Tutti gli altri comportamenti sono identici a quelli dell’MCP23017. Le operazioni eseguite dall’MCP23017 sono veloci come gli I/O, I2C o SPI.
Per il clock della MCK dello Switchinator, ho utilizzato un cristallo da 16 MHz, principalmente perché ne ho molti. Per lo Switchinator, l’oscillatore RC interno dell’AVR probabilmente va bene. Anche se il cristallo permette alla MCU di funzionare a una determinata velocità, aggiunge anche alcune complicazioni con i fuse bit interni che la MCU AVR utilizza per la configurazione interna. Come si leggono e come si impostano è spiegato in “Impostare i fuse bit della MCU AVR per un cristallo da 16 MHz” a pagina 420. I quattro input analogici sono collegati a una coppia di morsettiere da quattro posizioni. Le posizioni rimanenti sono utilizzate per V+, messa a terra e riferimento analogico opzionale e input AVCC. I jumper JP10 e JP11 servono a selezionare fonti di tensione esterne eliminandole dalla PCB. Due dei pin digitali della MCU (D0 e D1) servono per l’interfaccia RS-232 seriale. Tre
dei pin digitali (D11, D12 e D13) servono per l’interfaccia di programmazione ICSP. Gli altri pin digitali non sono assegnati. Quattro degli input analogici (A0, A1, A2 e A3) si utilizzano come input analogici per scopi generali. I pin A4 e A5 si utilizzano per l’interfaccia I2C tra la MCU e l’IC dell’MCP23017. La Tabella 10-10 elenca le assegnazioni dei pin dello Switchinator. Tabella 10-10 - L’utilizzo dei pin nella MCU dello Switchinator.
Pin D0
D1
D2
Funzione RxD per RS-232
TxD per RS-232
Non utilizzato
Pin D7
D8
D9
Funzione Non utilizzato
Non utilizzato
Non utilizzato
Pin
Funzione
A0
Input analogico per impieghi generici
A1
Input analogico per impieghi generici
A2
Input analogico per impieghi generici
D3
Non utilizzato
D10
Non utilizzato
A3
Input analogico per impieghi generici
D4
Non utilizzato
D11
ICSP MOSI
A4
I2C SCL
D5
Non utilizzato
D12
ICSP MISO
A5
I2C SDA
Basandoci sullo schema presentato nella Figura 10-21, possiamo generate un elenco dettagliato di parti come mostra la Tabella 10-11. Tabella 10-11 - L’elenco di parti dello Switchinator.
Quantità
Descrizione
Quantità
Descrizione
2
Condensatore, 0,1 uF
4
LED rosso
2
Condensatore, 10 uf
1
LED verde
2
Condensatore, 27 pF
5
Resistenza 1 kohm, 5%, 1/4 W
1
Condensatore, 0,001 uF
1
Resistenza 10 kohm, 5%, 1/4 W
4
Condensatore, 1 uF
1
Resistenza 330 ohm, 5%, 1/4 W
1
Diodo 1N4001
1
Interruttore, pulsante tattile MCU ATmega328, DIP da 28
1
Expander I/O MCP23017 I2C
1
pin
2
Dirver di output ULN2003A
1
Ricetrasmittente MAX232 RS232, DIP da 16 pin
1
Jack di alimentazione, 5,5 mm cilindrico
1
Regolatore di tensione 7805, TO-220
1
Pacchetto di connettori AVR ISP, 2 × 3 pin
1
Connettore DB9, montato sulla PCB, maschio
6
Morsettiera, passo 3,5 mm
1
Cristallo da 16 MHz
2
Header di jumper da 2 pin
1
PCB personalizzata
Il software Come nel progetto della GreenShield, la parte più complessa dello Switchinator in realtà è il software. La Figura 10-23 mostra un diagramma a blocchi del software.
Figura 10-23 - Un diagramma a blocchi del software dello Switchinator.
Quando lo Switchinator è in attesa di input di comandi, invia un unico carattere “>” seguito da uno spazio. Le risposte sono precedute dal carattere “<” e da uno spazio, seguiti dai dati della risposta. L’utilizzo dei caratteri “>” e “<” avviene principalmente per comodità del software attivo sul sistema dell’host di controllo. Tutte le righe degli input e degli output terminano con un carattere nuova riga (\n o 0x0A). A ogni passaggio nel ciclo principale, vengono letti gli input analogici e vengono salvati i
valori. Questi sono restituiti all’host di controllo quando è richiesto un risultato analogico, che significa che saranno aggiornati al ritmo del ciclo principale. Quindi, il software controlla se stanno arrivando dati seriali. Se ci sono dati nel buffer degli input, viene chiamata la funzione di lettura degli input per leggere i caratteri finché non viene trovata una nuova riga (il relativo carattere), il valore ASCII 10 (0x0A o \n). Poi il parser estrae il comando dalla stringa, analizza i parametri ed esegue l’operazione richiesta. Il controllo dello Switchinator avviene per mezzo di un semplice protocollo comandorisposta. Per ogni comando o query inviata dall’host di controllo, lo Switchinator risponde con un’unica risposta. Lo Switchinator non inizia mai transazioni di comunicazione con l’host di controllo. Il protocollo comando-risposta completo è mostrato nella Tabella 10-12. Tabella 10-12 - Il protocollo comando-risposta dello Switchinator.
Descrizione
Formato in/out
Comando
Risposta
A:n
A:n:val
Ottiene l’input analogico n in raw DN
Esadecimale
R:nM
R:n:val
Legge lo stato dell’output n
Esadecimale (0 o 1)
W:n:val
OK
Scrive 0 o 1 sull’output n
Esadecimale
S:val
OK
Imposta tutti gli output sul valore esadecimale
Esadecimale 4 cifre
G:?
G:val
Ottiene il valore esadecimale di tutti gli output
Esadecimale 4 cifre
Il comando per impostare è semplice e soltanto il comando W (write) utilizza due parametri anziché uno solo. Tutti i valori di parametri e risposte sono nella notazione esadecimale. Questo permette ai numeri delle porte digitali di essere cifre uniche esadecimali, mentre i valori degli input analogici (il comando A) e i comandi per impostare e ottenere in massa (S, o imposta tutte le porte, e G, ottieni tutte le porte, rispettivamente) utilizzano valori esadecimali di quattro cifre. Le cifre 0 e 1 nominalmente sono nel formato esadecimale, ma nella notazione decimale sono uguali. Il rilevamento degli errori è gestito esaminando la stringa restituita dallo Switchinator. Se i comandi A, R o G restituiscono la stringa inviata, si produce un errore. Se i comandi S o W incontrano un errore, restituiscono la stringa originale. Se la loro azione va a buon fine, viene restituita la stringa “OK”.
Numeri ottali ed esadecimali Se sapete già lavorare con le notazioni ottale ed esadecimale, potete saltare questo riquadro. In caso contrario,
ecco una breve storia che vi permetterà di scoprire da dove vengono questi sistemi numerici per il software e come funzionano. Tempo fa, quando i computer occupavano intere stanze e generavano tanto calore che ci si poteva cuocere un uovo, è diventato rapidamente ovvio che gestire i numeri binari non avrebbe funzionato molto bene. E, dato che le macchine erano intrinsecamente binarie, i valori decimali non si mappavano facilmente ai pattern di bit delle luci del pannello di controllo o salvati nella memoria. La soluzione è stata rappresentare i valori numerici utilizzando una base numerica diversa da 2 o da 10. Il caso è che ci sono due sistemi di base che hanno una mappatura diretta con i valori binari: quello ottale (con base 8) e quello esadecimale (con base 16). Il sistema di numerazione ottale con base 8 si è diffuso sui computer che per i dati e gli indirizzi utilizzavano parole di 12, 24 o 36 bit, dal momento che il valore di ciascuna dimensione può essere diviso esattamente per 3. Una cifra ottale può avere un valore compreso tra 0 e 7, per cui le cifre ottali si mappano ciascuna su tre bit. La Tabella 10-13 mostra come funziona. Tabella 10-13 - Il sistema di numeri ottali su un computer a 12 bit. Decimale
Binario
Ottale
Decimale
Binario
Ottale
0
000 000 000 000
0000
9
000 000 001 001
0011
1
000 000 000 001
0001
10
000 000 001 010
0012
2
000 000 000 010
0002
20
000 000 010 100
0024
3
000 000 000 011
0003
30
000 000 011 110
0036
4
000 000 000 100
0004
40
000 000 101 000
0050
5
000 000 000 101
0005
50
000 000 110 010
0062
6
000 000 000 110
0006
100
000 001 100 100
0144
7
000 000 000 111
0007
200
000 011 001 000
0310
8
000 000 001 000
0020
511
000 111 111 111
0777
I numeri ottali si trovano ancora nei moderni computer Unix e Linux, come i bit dei permessi dei file, ma altrimenti oggigiorno sono rari. Nessuno utilizza più computer da 12 o 24 bit per scopi generali, anche se alcuni gruppi di ricerca hanno creato design di microprocessori da 24 bit per applicazioni specifiche e il dispositivo DSP (digital signal processor) DSP56303 di Freescale può essere utilizzato come una macchina da 24 bit. Mentre le architetture dei computer passavano a dimensioni di dati e indirizzi che sono multipli di 4, il sistema ottale diventava rapidamente obsoleto. La soluzione era il sistema esadecimale con base 16. Nel sistema di numerazione esadecimale, ciascuna cifra può rappresentare un valore compreso tra 0 e 15, o binario tra 0000 e 1111. In altre parole, ciascuna cifra esadecimale è una “pezzettino” e due cifre esadecimali rappresentano un “byte” di 8 bit. Tuttavia, la notazione esadecimale presenta un problema. In numeri a base 10 non possono rappresentare nessun valore maggiore di 9 con una sola cifra. Il valore 10 si scrive con due cifre. Durante gli anni ’50, sono stati proposti diversi schemi per cercare di risolvere il problema della notazione, alcuni dei quali oggi possono sembrarci molto strani. Dopo qualche anno, hanno cominciato a prendere polvere e siamo finiti con 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E ed F per i valori da 0 a 15. La Tabella 10-14 mostra la relazione tra i valori decimali, binari ed esadecimali di una serie di numeri. Tabella 10-14 - Il sistema di numerazione esadecimale su un computer a 16 bit. Decimale
Binario
Esadecimale
0
0000 0000 0000 0000
0000
1
0000 0000 0000 0001
0001
2
0000 0000 0000 0010
0002
3
0000 0000 0000 0011
0003
4
0000 0000 0000 0100
0004
5
0000 0000 0000 0101
0005
6
0000 0000 0000 0110
0006
7
0000 0000 0000 0111
0007
8
0000 0000 0000 1000
0008
9
0000 0000 0000 1001
0009
10
0000 0000 0000 1010
000A
20
0000 0000 0001 0100
0014
30
0000 0000 0001 1110
001E
40
0000 0000 0010 1000
0028
50
0000 0000 0011 0010
0032
100
0000 0000 0110 0100
0064
200
0000 0000 1100 1000
00C8
255
0000 0000 1111 1111
00FF
511
0000 0001 1111 1111
01FF
4095
0000 1111 1111 1111
0FFF
Nel software, a volte vedrete valori esadecimali scritti come 0x3F in C e C++, 3Fh in linguaggio assembly, $3F in Forth, oppure %3F in un URL. Un display LED numerico a sette segmenti può gestire i valori esadecimali modificando la visualizzazione di alcune delle cifre per ottenere simboli che si presentino come A, b, c, d, E e F, come mostra la Figura 10-24.
Figura 10-24 - Una visualizzazione esadecimale con un normale a display LED a 7 segmenti. Presto, è diventato rapidamente evidente sia nel sistema di numerazione ottale che in quello esadecimale che ci sono alcuni valori speciali, a volte detti “numeri magici”, che continuano ad apparire. Per esempio, nel sistema esadecimale il valore 0xFF è un byte con tutti i bit impostati su 1. 0x5A5A è un pattern alternativo (binario 0101 1010 0101 1010) che a volte si utilizza come riempitivo per controllare l’uso degli stack o per sovrascrivere un hard disk per cancellare dati salvati in precedenza. 0x7F è 127, 0x1FF è 511 e 0x3FF è 1023. 0x3FF (1023) è il valore massimo che può produrre l’ADC da 10 bit dell’AVR ATmega328 e 0x1FF è il punto intermedio del suo intervallo. È possibile eseguire calcoli sia con numeri ottali che esadecimali e nella programmazione in linguaggio assembly spesso c’è bisogno di aggiungere o sottrarre valori di indirizzi esadecimali (per indirect jump o istruzioni branch relative, per esempio). Eseguire calcoli come la moltiplicazione e la divisione con numeri esadecimali è possibile, ma richiede un po’ di pratica. A meno che non vogliate o abbiate bisogno di scrivere molta programmazione a basso livello in linguaggio assembly, i calcoli esadecimali probabilmente sono qualcosa che non dovrete aggiungere alle vostre capacità, ma per lavorare con i microcontroller dovete essere capaci di tradurre da esadecimale a binario (e viceversa).
Il comando A accetta una sola cifra compresa tra 0 e 3 e i dati analogici sono il valore vero e proprio restituito dall’ADC della MCU AVR. È restituito come un valore esadecimale da 1 a 3 cifre, con il valore massimo possibile pari a 0x3FF. I comandi R e W hanno lo specifico numero di porta dell’output digitale nella forma di un’unica cifra esadecimale, che va da 0 a 0xF (15). I canali di output 7 e 0xF sono utilizzati per i LED integrati sulla scheda; non sono collegati per mezzo dei driver ULN2003A. Nella Tabella 10-12 potete notare che per controllare o ottenere lo stato di più di un output si utilizzano i comandi S e G con un valore esadecimale. Con questo schema, possiamo attivare (impostare sullo stato on) output non contigui o leggere lo stato di tutti gli output. Se, per esempio, volessimo impostare gli output 5, 6, 12 e 13 sullo stato on, dovremmo inviare il valore 3060h, che in binario si traduce così:
Ricordate che la numerazione dei canali parte da zero. SUGGERIMENTO Inviare un valore esadecimale farà sì che lo stato degli output cambi per adattarsi al valore del comando. Questo significa che se un output è on e il valore del comando ha uno zero in quella posizione, diventerà off. Per impostare o cancellare un determinato output senza disturbare gli altri bit, si utilizza un’operazione lettura-modificascrittura (legge i bit, modifica i dati, imposta i bit). Ecco come funziona il comando W.
L’ultimo passaggio del ciclo trasferisce i bit dello stato dell’output digitale sull’hardware. Se non sono state applicate modifiche dal momento dell’ultimo aggiornamento, gli output non faranno niente. Altrimenti, i bit che sono stati cambiati appariranno come modifiche dello stato on oppure off degli output dell’ULN2003A.
Il prototipo Il prototipo si concentra soprattutto sull’interfaccia RS-232 e sul protocollo di controllo comando-risposta e quindi il suo hardware è rappresentano principalmente da un ATmega328 montato su una breadboard che non richiede saldature. In sostituzione del MAX232 della scheda finale, si utilizza un modulo adattatore RS-232. La Figura 10-25 mostra il prototipo.
Figura 10-25 - Il prototipo dello Switchinator.
Il modulo RS-232 è un’unità autonoma con un IC MAX3232. Dal punto di vista funzionale, questa parte è equivalente al MAX232 utilizzato nello Switchinator. Nominalmente, il MAX3232 è una parte a 3,3 V, anche se tollera 5 V. È anche leggermente più cara del MAX232. La Figura 10-26 mostra un ingrandimento del modulo di interfaccia RS-232.
Figura 10-26 - Il modulo di interfaccia RS-232.
Questi moduli sono reperibili presso diversi rivenditori per un prezzo compreso tra i 3 $ e i 6 $. Cercando su Google “arduino rs232 module” oppure “arduino rs232 converter”, si trovano numerosi risultati. La maggior parte dei computer desktop sono ancora dotati di un’unica porta RS-232 e di un connettore DB-9 sul pannello posteriore, ma se possedete un modello più recente di PC portatile potete non avere a disposizione una porta seriale. Per aggirare questo problema, potete utilizzare un adattatore USB-RS232. Questi hanno un prezzo che oscilla tra i 4 $ e gli oltre 30 $ e alcuni tipi speciali costano anche di più. Per maggiori dettagli su RS-232 e sui connettori che utilizza, vi consiglio di leggere i miei libri Real World Instrumentation with Python e Practical Electronics: Components and Techniques (vedere Appendice D). Entrambi contengono paragrafi che trattano specificamente RS-232, i connettori DB-9, gender changer e come collegare un DB-9 per permettere comunicazioni RxD/TxD senza segnali di handshaking.
Impostare i fuse bit della MCU AVR per un cristallo da 16 MHz A differenza degli altri esempi mostrati in questo libro, lo Switchinator non è una scheda Arduino. Può essere compatibile con il software se è installato il bootloader, ma questo non è obbligatorio. Fondamentalmente, è soltanto un design per una MCU AVR. Questo significa che la MCU non è preconfigurata come con una scheda Arduino. Un MCU nuova di Atmel girerà nella modalità RC clock utilizzando un oscillatore interno da circa 8 MHz. Se è stato installato un bootloader, sono impostati alcuni interruttori interni che indicano che è stata riservata una parte dello spazio di memoria flash. Inoltre, le MCU con firmware del bootloader precaricato di solito hanno i fuse bit impostati per un cristallo esterno da 16 MHz, ma una parte nuova di zecca presenterà soltanto la configurazione predefinita. Per configurare la MCU in modo che possa utilizzare il cristallo da 16 MHz come la sua sorgente di clock dobbiamo impostare i fuse bit. Per maggiori dettagli sui fuse bit utilizzati nelle MCU AVR, potete rileggere “I fuse bit” a pagina 62 nel Capitolo 3. La fonte definitiva di informazioni è, naturalmente, la scheda tecnica di Atmel della MCU AVR che state utilizzando. Se volete utilizzare la configurazione di Arduino per AVRDUDE (e avete un sistema Linux), ecco il comando che vi serve per un ATmega328:
Per una parte ATmega328p dovete semplicemente cambiare il parametro relativo alla parte, così:
Su un sistema Linux, se avete impostato i permessi per gli I/O USB, non dovete utilizzare sudo per eseguire avrdude. Per ulteriori informazioni sulle opzioni a linea di comando e i comandi interattivi supportati da avrdude, potete consultare il manuale online (http://bit.ly/avrdude-manual). L’ultimo passaggio è informare il compilatore del fatto che adesso si utilizzano 16 MHz. Per farlo, si deve definire F_CPU così: Di solito, questa riga viene aggiunta dall’ambiente di Arduino quando si lavora con una scheda Arduino convenzionale, ma con una scheda target personalizzata può diventare necessario specificare esplicitamente la velocità del clock. Le versioni per Windows e per Mac OS di AVRDUDE si comportano nella stesso modo che su Linux. In questo tutorial (http://www.ladyada.net/learn/avr/setup-win.html) trovate ulteriori informazioni sulla versione per Windows di AVRDUDE.
Il software del prototipo Il software del prototipo è essenzialmente uguale a quello della versione finale, soltanto senza il codice per impostare gli output digitali per mezzo dell’MCP23017. L’obiettivo principale del prototipo è l’implementazione del protocollo comando-risposta. Gli stati degli output sono rappresentati come in una word da 16 bit nel software. “Il software” a pagina 423 contiene una descrizione dettagliata del software e quindi, anziché presentarla qui e magari ripeterne delle parti successivamente, vi consiglio di cercare là i dettagli. Il software viene compilato utilizzando l’IDE di Arduino e quindi caricato sulla MCU AVR utilizzando un dispositivo di interfaccia ICSP USBtinyISP di Adafruit. Per gestire la compilazione, io ho utilizzato l’IDE di Arduino, ma ho disattivato il suo editor interno nella finestra di dialogo Preferences. In questo modo, ho potuto utilizzare un altro editor (per vivere scrivo software commerciale e scientifico e quindi ho determinate preferenze in merito agli editor di testo: non sono un grande ammiratore dell’editor dell’IDE di Arduino). La scheda è stata impostata su “Duemilanove with ATmega328” e il programmatore su “USBtinyISP”. Su un sistema Linux, l’USBtinyISP non utilizza una porta pseudo-seriale, ma comunica direttamente con il sottosistema I/O USB sottostante. Cercare di eseguire l’IDE di Arduino con il programmatore all’inizio produrrà un errore di permessi. Potete eseguire l’IDE di Arduino utilizzando sudo, ma questo non è un modo comodo di trasferire il vostro codice. Per aggirare questo problema, dovete aggiungere una regola di accesso per l’ handler udev. Basta creare un file in /etc/udev/rules.d di nome tinyusb.rules e aggiungervi questa stringa:
Per farlo, io ho utilizzato vi e sudo:
Quindi, per rendere effettiva questa nuova regola, dobbiamo riavviare il sottosistema udev:
Potete anche utilizzare qualche altro tipo di dispositivo di programmazione (perfino un altro Arduino, come descritto nel Capitolo 6). Io ho un Atmel-ICE, ma alla fine non l’ho utilizzato su Linux perché non disponevo dell’ultima versione di AVRDUDE ed ero troppo pigro per costruirla e mettermi a giocherellare con i file di configurazione. Funziona con il software AVR Studio di Atmel e quindi, se utilizzate Windows, potete decidere di prendere questa strada. Sul mio sistema Linux il piccolo gadget di Adafruit funziona bene. Utilizzando l’icona per caricare della mia versione dell’IDE, questo cerca di comincia a
trasferire utilizzando il metodo USB-seriale costruito nelle schede Arduino (e supportato da un convertitore USB-seriale come quello menzionato prima). Questo non funzionerà con l’USBtinyISP e quindi utilizzo invece l’opzione File→Upload Using Programmer. Una cosa che ho notato è che il software di trasferimento AVRDUDE è lento a cominciare, ma diventa veloce una volta che ha stabilito un link di comunicazione solido con la MCU AVR. Potete vederlo sia nell’IDE di Arduino sia eseguendo AVRDUDE dalla linea di comando. Non dovete entrare in panico se sembra che tutto si blocchi: non è così. Se si verifica un problema, alla fine AVRDUDE farà timeout e vi dirà che cosa è andato storto.
Testare il prototipo Testare il prototipo è facile e questo paragrafo descrive i test da eseguire specificamente sul parser dei comandi. La possibilità di interagire correttamente con il software dimostrerà che la porzione di codice relativa all’RS-232 funziona correttamente. Si dà per scontato che la ricetrasmittente RS-232 esterna funziona come previsto. Innanzitutto, vengono testati i comandi per l’output (OUT), lo stato (ST) e l’input (AN). I comandi OUT:A:1 e OUT:A:0 si utilizzano per impostare tutto on o tutto off. Lo stato di ciascun output è conservato nella memoria in modo che a questo punto non ci sia bisogno di hardware per l’output. Con il comando ST:n:?, il n parametro è un’unica cifra compresa tra 0 e 13 (D in esadecimale). Notate che anche le forme dei comandi OUT:n:0 e OUT:n:1 utilizzano un’unica cifra. Se il software funziona correttamente, è possibile impostare tutti gli output su off (0) e quindi attivare e disattivare selettivamente un output qualsiasi da 0 a 13 senza alterare nessuno degli altri output. Il comando per gli input analogici (AN) viene testato applicando una sorgente di tensione variabile (soltanto da 0 a 5 V) ad A0 fino ad A3 e richiedendone il valore. Dal momento che la tensione dell’input viene cambiata, devono cambiare anche i dati restituiti. Il valore dell’input è restituito nella forma di valore esadecimale da tre cifre. Il due bit più significativi sono sempre 0 (la MCU AVR ha soltanto un ADC da 10 bit). I comandi SP:val e GP:? utilizzano un valore esadecimale da quattro cifre, come descritto prima. Per testarlo, si devono impostare tutti gli output dispari su on e tutti gli output con numerazione pari su off, quindi controllare gli stati di ciascuno utilizzando il comando ST. Gli output con numerazione dispari saranno impostati su off e quelli pari su on e gli stati dei bit degli output saranno di nuovo controllati utilizzando il comando ST.
Il software Anche se è possibile e spesso consigliabile creare una versione semplificata del software da utilizzare con il prototipo, nel caso dello Switchinator prende vita come serie di codici multifile. Il file principale è, naturalmente, Switchinator.ino. Gli altri file della serie contengono le definizioni globali, le variabili globali, il parser dei comandi, il
generatore di risposte e il codice di controllo degli I/O. Il modulo I/O, sw_io.cpp, non è necessario nella versione del prototipo del software.
L’organizzazione del codice sorgente Il codice sorgente Switchinator è formato da otto file, o moduli, descritti nella Tabella 10-15. Il modulo principale, Switchinator.ino, contiene le funzioni setup() e loop(). Fa anche riferimento ad altri moduli utilizzando dichiarazioni #include. Tabella 10-15 - I moduli del codice sorgente dello Switchinator.
Modulo Switchinator.ino
Funzione Modulo principale che contiene setup() e loop()
sw_defs.h
Definizioni delle costanti (dichiarazioni #define)
sw_gv.cpp
Variabili globabali
sw_gv.h sw_io.cpp sw_io.h sw_parse.cpp sw_parse.h
File include Funzioni I/O hardware File include Parsing dei comandi File include
L’elenco completo di tutti i file sorgente dello Switchinator è disponibile su GitHub.
La descrizione del software Come nel caso di qualsiasi programma Arduino, l’azione comincia nello sketch principale. I contenuti del file principale Switchinator.ino sono elencati nell’Esempio 10-9. Esempio 10-9 - Switchinator.ino.
La funzione setup() contiene le solite dichiarazioni di inizializzazione insieme al messaggio di avvio iniziale. La funzione loop() aggiorna continuamente i bit dell’output e controlla se ci sono dei comandi in arrivo da un sistema di host di controllo per mezzo della funzione GetCommand() che si trova nel modulo SW_parse.cpp. Tornando alla Figura 10-23, il blocco “Get command string” si riferisce alla funzione GetCommand() che si trova nel modulo sw_parse.cpp, i blocchi di funzioni “Parse” e “Generate response” sono contenuti nella funzione DecodeCommand() e “Update digital output bits” si trova nella funzione SetDigBits() contenuta nel modulo sw_io.cpp. La Figura 10-27 mostra come il buffer dello stato dei bit dell’output, gv_statebits, viene utilizzato per contenere una rappresentazione interna dei bit dell’output. Tutte le funzioni di modifica dei bit agiscono su gv_statebits, non sugli output digitali veri e propri.
Figura 10-27 - Il buffer virtuale di bit dello Switchinator in azione.
Notate che scrivere 0x00 sulla porta A oppure sulla porta B attiva anche il LED della porta associato. Scrivere 0xFF su una delle porte ne disattiva il LED. I bit dell’output sono aggiornati circa ogni 50 ms, se non è presente un input seriale da analizzare e
decodificare.
La produzione Per il design dell’hardware, ho utilizzato lo strumento Fritzing. Si tratta di uno strumento che offre una breadboard virtuale integrata, la possibilità di catturare schemi e di creare layout di PCB e che è facile da installare e relativamente facile da utilizzare. Fritzing ha un’ampia e vivace base di utenti e molte parti precaricate nella sua libreria. E il bello è che è gratuito. Alcune distribuzioni Linux possono avere una versione più vecchia di Fritzing nel loro repository, ma potete scaricare quella più recente da http://fritzing.org/home. Io ho utilizzato la versione 0.8.5 su un sistema Linux Kubuntu 14.04 LTS. Esistono versioni di Fritzing anche per Windows e Mac OS X. In confronto ad altri strumenti con i quali ho lavorato nel corso degli anni, sono rimasto piacevolmente sorpreso di quanto è facile da utilizzare l’interfaccia utente di Fritzing. A essere onesti, non sono rimasto altrettanto impressionato dall’autorouter, ma poi ho visto autorouter high-end lottare con cose che pensavo che fossero facili. E il software di autorouting è molto difficile da programmare e quindi non mi aspettavo un miracolo. Ho finito per creare il layout manualmente (e sono sicuro che si vede). Il DRC (design rules check) ha funzionato bene e, anche se l’editor di schemi presenta alcune stranezze, anche quello era completamente usabile. La mia critica principale a Fritzing è rivolta alla libreria delle parti. Sembra che non tutte si trovino sulla stessa pagina, quando si tratta di dimensioni dei simboli schematici, e quindi le parti di una libreria aggiuntiva possono essere molto piccole, mentre quelle fornite da Fritzing presentano simboli grandi e belli. Lo vedrete quando guarderete lo schema nella Figura 10-21. Il risultato è che, a meno che tutte le parti contenute in una libreria di strumenti (sia i simboli che le impronte del layout) non rispettino gli stessi limiti di dimensionamento, è difficile ottenere linee o tracce perfettamente ortogonali senza dover giocare seriamente con le funzioni di ridimensionamento e di aggancio della griglia. Una volta che lo schema (mostrato nella Figura 10-21) è completo, si può cominciare a creare il layout della PCB. La prima volta che appare il layout della PCB, non contiene tracce, soltanto le linee a nido di topo che indicano quali pin sono collegati sulle parti. Nella Figura 10-28 ho già collocato i componenti dove credo che debbano andare e Fritzing sta mostrando alcune delle linee a nido di topo. Facendo clic e tenendo premuto il pulsante del mouse su un pin di una parte qualsiasi, vengono evidenziati in giallo tutti i punti dove lo si può collegare.
Figura 10-28 - La PCB dopo il posizionamento delle parti, ma prima del routing.
I componenti sono raggruppati in base alla funzione: l’alimentazione si trova nella parte in basso a sinistra della PCB; l’MCP23017 e i due ULN2003A si trovano nella zona in alto a sinistra; la MCU, il cristallo, il connettore ICSP e gli input analogici si trovano in alto a destra; e l’interfaccia seriale si trova in basso a destra nel layout. Potete notare che ho invertito i simboli delle morsettiere degli input analogici per semplificare il collegamento. Verranno comunque montate correttamente e, dal momento che un prototipo di PCB come questo non ha una serigrafia sullo strato superiore, non fa nessuna differenza. Il routing delle tracce in alcuni casi è piuttosto tortuoso, principalmente per via dell’utilizzo di parti through-hole. Per spostare le tracce tra le parti superiore e inferiore della PCB si utilizzano vie, che aiutano a evitare collisioni. La Figura 10-29 mostra la versione finale della PCB che è stata inviata in produzione.
Figura 10-29 - La versione finale del layout della PCB dello Switchinator.
Prima di inviare i file Gerber, ho ricontrollato il design con lo strumento Gerbv (che è stato presentato prima con la GreenShield). Potete vedere una cattura dello schermo nella Figura 10-30.
Figura 10-30 - La visualizzazione del layout della PCB su Gerbv.
Fortunatamente, la casa di produzione (Advanced Circuits) ha scoperto due piazzole che erano quasi, ma non abbastanza, collegate. Sarebbe stato facile correggerle sul tavolo da lavoro, ma sarebbe stato difficile riscontrarne i problemi. Per fortuna qualcuno lo ha notato e ha controllato i layout. Lo Switchinator è una PCB through-hole e quindi assemblarla è facile. La Figura 10-31 mostra la PCB prima che vi vengano installate le parti.
Figura 10-31 - La PCB dello Switchinator.
Le prime parti da saldare in posizione sono il jack DC e il regolatore 7805, insieme ai componenti dell’alimentazioni associati, che sono D1, C2, C3, C4 e C5. Notate che non c’è C1 (è sparito in una revisione precedente). Per testare l’alimentatore, abbiamo bisogno di installare anche R5 e LED5. Una volta che sono installate queste parti, possiamo collegarci a una presa da 9 a 12 V DC per mezzo del jack DC e verificare che il regolatore stia producendo 5 volt DC sull’anodo di LED5 (che deve illuminarsi). Quindi installeremo il connettore RS-232, etichettato X1 nello schema; U2 (l’IC MAX232); e C9, C10, C11 e C12. Utilizzando la breadboard per prototipare, possiamo collegare i segnali Rx e Tx dai pin 2 e 3 della MCU ai pin U1 2 e 3 sulla PCB. Quindi eseguiamo il software già sulla MCU AVR e verifichiamo che il nostro RS-232 integrato stia funzionando correttamente. Ricordate di legare la messa a terra e l’alimentazione 5 V DC dalla PCB alla breadboard (e di scollegare l’alimentatore della breadboard, naturalmente). Con l’alimentatore e l’interfaccia RS-232 installati e funzionanti, adesso possiamo installare U1 (la MCU), IC1, IC2 e IC3. Anche LED1, LED2, R1 e R2 possono essere saldati al loro posto, insieme alle sei morsettiere. Quindi, installiamo il cristallo, C6, C7, C8, R3, R4, R6, LED3 e LED4. Il pulsante di reset, S1 e il connettore ICSP sono le
ultime cose da montare sulla PCB. La Figura 10-32 mostra la PCB finita con tutto installato e pronto per funzionare. La tensione massima che possono fornire i driver dell’ULN2003A è determinata dall’alimentatore e dalle valutazioni degli IC. La scheda tecnica dichiara che l’ULN2003A è capace di fornire circa 300 mA per canale, o circa 2,1 A per IC. In confronto, l’ATmega328 e l’MCP23017 trasportano pochissima corrente e quindi la preoccupazione maggiore saranno sempre i dispositivi ULN2003A. Un alimentatore capace di fornire almeno 5 A dovrebbe essere più che sufficiente, se volete utilizzare lo Switchinator per qualcosa come un piccolo strumento CNC o un controller di display di LED.
Figura 10-32 - Lo Switchinator completato.
Il collaudo I test finali dello Switchinator completo sono ampiamente una ripetizione dei test eseguiti sul prototipo. La grande differenza, adesso, è che ci sono due driver ULN2003A e un’interfaccia RS-232 integrata basata su un IC MAX232. Deve essere testato anche l’alimentatore, oltre agli input analogici.
Prossimi passaggi Qui, non sono stati utilizzati tutti i pin I/O digitali discreti della MCU: rimangono disponibili 10 pin (6 dei quali capaci di output PWM). Io non li ho collegati per via dei limiti di spazio della PCB, ma sarebbe possibile modificare la PCB in modo che possa accogliere un paio di pin socket da sei posizioni. Questo, tuttavia, richiederebbe un utilizzo astuto di vie per dirigere le tracce nel traffico intorno alla MCU. L’interfaccia SPI è disponibile sui pin D11, D12 e D13 e questi sono collegati al
connettore ICSP. Se selezionate un pin inutilizzato per la linea SS, potete collegare un modulo SPI allo Switchinator. I pin analogici possono essere utilizzati come pin I/O digitali facendovi riferimento come pin dal D14 al D19. Potete aver notato che non ci sono fusibili né protezione degli input per gli input analogici. Per vedere un esempio di protezione degli input analogici, potete andare nel Capitolo 11 e guardare il circuito di input utilizzato per il generatore di segnale.
Fonti Questo capitolo si è mosso in un territorio molto ampio e ha compiuto un paio di salti. Ecco alcune fonti che vi possono aiutare a gettare più luce sugli argomenti che in questo testo sono stati trattati soltanto brevemente: Testi di riferimento Esistono numerosi testi che parlano di tutti gli aspetti dell’elettronica. Questi sono quelli ai quali sono particolarmente affezionato e che hanno a che vedere direttamente con il materiale trattato in questo capitolo (nell’Appendice D trovate i numeri ISBN e ulteriori testi raccommandati): •
Jan Axelson, Making Printed Circuit Boards
•
Paul Horowitz e Winfield Hill, The Art of Electronics, 2ª Edizione
•
J. M. Hughes, Practical Electronics: Components and Techniques
•
J. M. Hughes, Real World Instrumentation with Python
•
Simon Monk, Fritzing for Inventors
•
Matthew Scarpino, Designing Circuit Boards with EAGLE
Cattura degli schemi e layout delle PCB Fritzing e Eagle non sono gli unici strumenti CAD per elettronica esistenti, ma sono quelli che si incontrano più spesso quando si scaricano schemi o layout di schede creati e pubblicati online da altri. Fritzing è gratuito e open source ed esistono molte fonti per le definizioni delle parti oltre a quelle che include. È facile da imparare e facile da utilizzare e per i progetti Arduino è una buona scelta. La versione gratuita di Eagle ha tre funzionalità che si trovano nelle versioni commerciali dello strumento e quindi presenta un chiaro percorso di aggiornamento quando volete esplorare il mondo degli strumenti CAD/CAM professionali per l’elettronica. Ricordate soltanto che la versione gratuita di Eagle presenta alcuni limiti e non è pensata per essere utilizzata nelle situazioni nelle quali pensate di guadagnare soldi per il vostro lavoro. Per quelle, dovrete acquistare una licenza commerciale. Alcune altre opzioni di strumenti CAD sono strumenti Linux open source come la
suite gEDA e KiCad, entrambi i quali hanno funzionalità comparabili a quelle dei prodotti commerciali. Per ulteriori informazioni sugli strumenti menzionati qui, potete visitare i loro siti web: •
Eagle (http://www.cadsoftusa.com/download-eagle)
•
Fritzing (http://www.fritzing.org)
•
gEDA (http://www.geda-project.org)
•
KiCad (http://kicad-pcb.org)
Produttori di PCB Esistono molte aziende che producono PCB e offrono prezzi bassi e tempi rapidi. Cercate sul Web e, se per caso vivete in una grande area metropolitana, assicuratevi anche di controllare quali servizi avete a disposizione localmente. Io ho menzionato Advanced Circuits soprattutto perché ho una maggiore familiarità con loro e non ho mai avuto problemi con il loro lavoro. Anche ragazzi di Fritzing.org offrono un servizio di produzione di PCB (potete accedervi dallo strumento Fritzing): •
Advanced Circuits (http://www.4pcb.com/bare-bones-pcbs)
•
Fritzing Fab (http://fab.fritzing.org/fritzing-fab)
Componenti In questo libro, ho fatto riferimento a molte fonti diverse per tutto, da singoli componenti a moduli e schede Arduino complete. Ecco alcune società che possono rappresentare dei punti di partenza da prendere in considerazione (ne trovate altre nell’Appendice C): •
Adafruit (http://www.adafruit.com)
•
All Electronics (http://www.allelectronics.com)
•
DigiKey Electronics (http://www.digikey.com)
•
Mouser Electronics (http://www.mouser.com)
•
Newark/Element14 (http://www.newark.com)
•
SparkFun (http://www.sparkfun.com)
11 Progetto: un generatore di segnale programmabile
Quasi tutti i laboratori di elettronica, che siano grandi o piccoli, hanno bisogno di sorgenti di segnale. In alcuni casi, può trattarsi di semplici generatori di onde sinusoidali e in altre situazioni possono essere richiesti strumenti più complessi come un generatore di funzioni. Il generatore di segnale descritto in questo capitolo, mostrato nella Figura 11-1, è capace di generare entrambi i tipi di output, ossia onde sinusoidali e quadre, fino a 40 MHz.
Figura 11-1 - Un generatore di segnale DDS fatto in casa.
Ovviamente, è perfettamente possibile anche acquistare un generatore di segnale. I prezzi possono variare, a seconda dell’intervallo di frequenza, delle caratteristiche e delle funzionalità. Potete trovare kit di generatori di segnale e funzioni per prezzi che vanno dai 6 $ ai 50 $, per un dispositivo come quello mostrato nella Figura 11-2. All’altra estremità della scala ci sono gli strumenti professionali che costano centinaia o migliaia di euro o addirittura di più (per esempio, 72.000 $ per un generatore di forme d’onda arbitrarie multifunzione da 20 GHz usato).
Figura 11-2 - Il kit del generatore di funzioni FG085 (assemblato).
Anche se i kit vanno bene per generare forme d’onda, possono non disporre di tutte le funzionalità o le caratteristiche che desiderate o delle quali avete bisogno. Dopo tutto, sono stati concepiti da qualcun altro e questa persona può avere una nozione diversa di che cosa rende utile un generatore di segnale. Costruendovelo da soli, potete ottenere esattamente quello che volete e potete modificarlo o espanderlo nel corso del tempo man mano che cambiano le vostre necessità. Una considerazione molto importante è come viene generato il segnale. In altre parole, il microcontroller sta facendo da solo tutto il lavoro, oppure delega il compito di generare le forme d’onda a un IC dedicato sul circuito? Nel caso del generatore di funzioni FG085 mostrato nella Figura 11-2, come controller principale dello strumento si utilizza ATmega168, per l’interfaccia USB si utilizza un CP2101 e il segnale viene generato da un ATmega48 e da un DAC che comprende una serie di resistenze. Questo approccio non presenta nessun problema e permette al generatore di fare ben più che semplicemente generare onde sinusoidali e quadre: può anche produrre forme d’onda arbitrarie a partire da pattern di dati precaricati (cosa che può rivelarsi molto utile). Lo svantaggio, quando si utilizza un microcontroller per generale il segnale, è che impone un limite alla frequenza più alta possibile che può generare il dispositivo. Nel caso di questo specifico generatore di funzioni, il limite si aggira sui 200 kHz. Non si tratta di un difetto dell’FG085, né di nessuno dei dispositivi che utilizzano un microcontroller in questo modo: è semplicemente un dato di fatto. Un microcontroller può girare soltanto a questa velocità e questa velocità massima del clock impone un limite massimo rigido su quanto velocemente può cambiare i suoi output per creare un segnale ciclico. Nel caso di molte applicazioni, 200 kHz vanno bene, in particolare nel mondo dei sensori e dei controlli incorporati. Come ho sottolineato prima, di solito le cose non vanno molto rapidamente nel mondo reale, almeno nelle scale di tempo in microsecondi dei microcontroller. Se vogliamo andare oltre i 200 kHz, dobbiamo scegliere un’altra soluzione. Fortunatamente, tutte le parti delle quali abbiamo bisogno per costruire un generatore di
segnale che possa generare onde sia sinusoidali che quadre fino a 40 MHz si trovano facilmente come moduli compatibili con Arduino. NOTA Trovate maggiori informazioni sull’FG085 sul sito web JYE Tech (http://bit.ly/jye-fg085). Insisto che non sto consigliando specificamente questo prodotto, ma che semplicemente ne possiedo uno che sta sul mio tavolo da lavoro con altri dispositivi da provare. Possiedo anche altri generatori di segnale e di funzioni, alcuni interessanti e altri meno, e tutti hanno un ruolo da giocare durante lo sviluppo e i testi di un nuovo design.
A dire la verità, adesso devo confessare che il generatore di segnale descritto in questo capitolo finirà per costare più del dispositivo da 50 $ mostrato nella Figura 11-2. Ne calcoleremo il costo totale quando creeremo l’elenco completo delle parti in “Il costo nel dettaglio” a pagina 470. Sarete voi stessi a dover decidere se il costo è giustificato in base al grado di controllo che avrete sul design e sul suo funzionamento e in base al metodo di packaging che ho scelto. Per quanto mi riguarda, ne valeva la pena, ma nel vostro caso potrebbe non essere così. NOTA Dovete ricordare che, dal momento che in questo libro l’enfasi principale è posta sull’hardware di Arduino e sui moduli, sensori e componenti correlati, il software qui è mostrato con l’unica intenzione +di sottolineare i punti chiave e non per presentare esempi completi e pronti da eseguire. Il codice completo del software degli esempi e dei progetti si trova su GitHub (https://www.github.com/ardnut).
Gli obiettivi del progetto In questo progetto, le fasi di definizione e pianificazione (descritte nel Capitolo 10) avvengono in un unico passaggio. Dal punto di vista fisico, il progetto non è specialmente complicato e quindi possiamo comprimere questi passaggi di sviluppo per risparmiare fatica e procedere più rapidamente. La parte più complessa è il software, come accade spesso quando si lavora con componenti hardware modulari di microcontroller. L’obiettivo di questo progetto è costruire un generatore di segnale adatto per essere utilizzato come strumento di prova. Anche se è perfettamente possibile utilizzare l’I/O digitale di un Arduino per generare onde quadre o impulsi, controllare un DAC di qualche tipo, oppure utilizzare gli output PWM per creare una forma d’onda che simuli un’onda sinusoidale, l’intervallo di frequenze di output è limitato dalla velocità del microcontroller. Esiste, tuttavia, un altro modo di utilizzare un Arduino per costruire un generatore di segnale e che richiede un IC generatore di segnale dedicato: l’AD9850. L’AD9850 è un chip DDS (direct digital synthesis) che può generare onde sia sinusoidali che quadre. Può essere programmato in modo che generi output da 0 a 40 MHz. Un modulo AD9850 facilmente reperibile è descritto nel Capitolo 9 e mostrato nella Figura 9-57. Dal momento che l’AD9850 gestisce la generazione del segnale al posto di Arduino, contemporaneamente possiamo utilizzare i cicli liberi della CPU per altre funzioni. L’aggiornamento di un display, il rilevamento dell’ingresso di controllo della porta esterna e il monitoraggio degli input dei controlli del funzionamento sono soltanto alcune delle cose che l’Arduino può fare mentre controlla l’IC DDS.
Questo significa anche che il generatore di segnale non ha bisogno di interrupt per gestire gli interruttori di controllo. Dal momento che l’AD9850 è sempre attivo (eccetto quando è attiva la modalità gate), la MCU può prendersi il tempo di interrogare i pulsanti e non interferirà con l’output del segnale.
La definizione e la pianificazione L’obiettivo di questo progetto è creare uno strumento di test portatile da utilizzare sul tavolo da lavoro oppure in un ambiente simile. Sarà alimentato da una presa da parete e la custodia offrirà spazio sufficiente per aggiungervi batterie in seguito, se lo si desidera. Output del segnale: •
Output di onde sinusoidali (sempre attivo), da 0 a 40 MHz, da 0 a 1 V P-P
•
Output di onde quadre (sempre attivo), da 0 a 40 MHz, da 0 a 5 V P-P
Input di controllo funzionale: •
ingresso di controllo della porta esterna
•
Input di controllo della tensione per il funzionamento del VCO
Interfaccia utente e controlli: •
Display LCD da due righe
•
Input select di frequenza (pulsanti)
•
Controlli del livello degli output del segnale output
•
Jack dell’ingresso della porta
•
Connettore BNC dell’ingresso CV
•
Accensione/spegnimento
L’intero progetto sarà costruito in una custodia di plastica con maniglia per trasportarla, come quella mostrata nella Figura 11-3. Il dispositivo sarà alimentato da una presa sulla parete con un output tra 9 e 12 V DC.
Figura 11-3 - La custodia portatile dello strumento.
Sul pannello frontale, il generatore di segnale incorporerà un display LCD da due righe che mostri la frequenza di output e lo stato, vari controlli di ingresso, ingresso CV (Control Voltage) e la porta di ingresso e output sia di onde sinusoidali (1 V P-P) sia di onde quadre (5 V P-P). Sul pannello posteriore ci sarà un connettore DC cilindrico per collegare un alimentatore esterno. L’elenco delle parti iniziali di questo progetto è fornito nella Tabella 11-1. Perfezioneremo questo elenco di parti man mano che procediamo, ma vi offre un’idea di quello che utilizzeremo. Un primo elenco di parti di solito subisce una serie di modifiche tra il momento del concepimento alla forma finale, alcune di minore importanza e altre piuttosto drastiche. Questo fa parte del processo di perfezionamento. Tabella 11-1 - L’elenco iniziale delle parti.
Quantità
Descrizione
Quantità
Descrizione
1
Arduino Uno
3
Connettori BNC femmina
1
Modulo DDS AD9850
2
Jack a banana (per la porta di ingresso)
1
Shield di prototipazione
1
Alimentatore da collegare alla parete
1
Display LCD da due righe
1
Contenitore di plastica
Il design Adesso che abbiamo definito gli obiettivi del design e un primo elenco di parti, possiamo cominciare a perfezionare il design. Cominceremo con la funzionalità che abbiamo pensato per definire che cosa farà esattamente il dispositivo e i controlli e gli I/O necessari per svolgere le funzioni previste. Dopo esserci fatti un’idea chiara di che cosa dovrà fare il generatore di segnale, possiamo dirigere la nostra attenzione alla custodia, dal momento che questa è dove verranno montate le parti e quello che alla fine determinerà che cosa potremo utilizzare per un display, gli input dei controlli e i connettori I/O. Qui, l’obiettivo è trovare un equilibrio tra la necessità di una custodia robusta e compatta e le considerazioni relative al costo e produzione. Dal momento che il progetto utilizza soprattutto moduli precostruiti, non sono necessari speciali design di circuiti né layout di PCB. I vari moduli e connettori del segnale dovranno essere collegati e quindi dovremo saldare qualcosa, ma lo vedremo nel passaggio relativo all’assemblaggio. Per gli input dei controlli del generatore di segnale, io ho scelto di utilizzare pulsanti, anziché un encoder rotativo come nel caso del design di alcuni generatori di segnale DDS che si trovano su vari siti web come Instructables (http://www.instructables.com/).
Il motivo è il fatto che l’encoder rotativo, anche se si rivela comodo per impostare rapidamente un valore, in realtà fa soltanto una cosa: misurare la quantità e la direzione della rotazione. I pulsanti, invece, possono fare diverse cose, a seconda di come vengono interpretati dal software nel contesto con altri controlli e dello stato dei dispositivi che devono controllare.
Le funzionalità Lo scopo principale di questo strumento è generare un segnale a una frequenza specifica compresa tra 0 e 40 MHz. L’AD9850 incorpora un comparatore integrato che si utilizza per creare un’onda quadra simultanea. L’onda sinusoidale è un segnale da 1 V P-P (peak-to-peak) è quella quadra è una da 5 V P-P. La frequenza di output è continuamente variabile da 0 a 40 MHz sotto il controllo di un Arduino Uno. La frequenza di output può essere variata esternamente dall’applicazione di un CV (control voltage) e può essere azionata (o gated) da un segnale esterno (che sia active high oppure active low). La Figura 11-4 mostra un diagramma a blocchi dello strumento con tutti i componenti identificati nella Tabella 11-1.
Figura 11-4 - Il diagramma a blocchi del generatore di segnale.
Il diagramma a blocchi della Figura 11-4 mostra tre componenti principali. L’Arduino gestisce gli input dei controlli: quelli forniti dall’utente così come la porta di ingresso e l’ingresso CV. Il display LCD mostra lo stato corrente dello strumento e il modulo DDS genera gli output di onde sinusoidali e onde quadre. Il diagramma a blocchi non offre dettagli di basso livello come i numeri e le polarità dei pin. Questo non è il suo scopo. Un diagramma a blocchi mostra in modo grafico come si relazionano le cose l’una con l’altra dal punto di vista funzionale. Serve anche per controllare se le ambizioni del design hanno superato le capacità dei componenti. Ho organizzato la Figura 11-4 in modo che gli output stiano sulla destra e gli input dei controlli sulla sinistra. Il grande simbolo circolare rappresenta un connettore di tipo BNC per i cavi coassiali schermati, mentre quello più piccolo rappresenta un jack del tipo a banana.
Un display LCD da 2 righe e 16 caratteri mostrerà la frequenza e lo stato correnti dei la porta di ingresso e dell’ingresso CV. Una serie di pulsanti servirà a regolare la frequenza e il funzionamento degli input dei controlli esterni. Due potenziometri serviranno a regolare il livello di output dei segnali di onde sinusoidali e quadre.
La custodia Per questo progetto, ho scelto la custodia Bud Industries IP-6130, che è mostrata nella Figura 11-3. Questa custodia include una maniglia per trasportarla, che si può anche piegare in modo che funga da supporto quando lo strumento si trova sul tavolo da lavoro, cosa che a volte si rivela molto utile. Potete scaricarne la scheda tecnica da Mouser Electronics (http://bit.ly/mouser-ip-6130). La custodia costa circa 25 $, ma io l’ho ritenuto un prezzo ragionevole da pagare per qualcosa che deve durare a lungo e offrire un aspetto professionale. Le dimensioni di base sono mostrate nella Figura 11-5. Per maggiori dettagli, potete consultare la scheda tecnica del prodotto.
Figura 11-5 - Le dimensioni della custodia portatile dello strumento.
Una cosa da notare è che i pannelli anteriore e posteriore non sono perfettamente rettangolari: sono più stretti sul bordo superiore che su quello inferiore, per adattarsi alla pendenza dei lati della custodia. Questo non è un problema, ma è importante notarlo perché i pannelli anteriore e posteriore si monteranno correttamente soltanto in un’orientazione. Tagliare i fori dei pannelli soltanto per scoprire che sono al contrario non sarebbe un disastro totale, ma potrebbe risultare imbarazzante (almeno per me). Le viti che tengono insieme la metà superiore con quella inferiore devono essere coperte con gommini protettivi che si trovano sul fondo della custodia. Notate anche che i pannelli anteriore e posteriore non presentano un’altezza sufficiente per poter montare su un Arduino e una pila di shield direttamente all’interno dei pannelli. Il modelloIP-6131 è più alto (3,54 pollici/8,99 cm), ma al suo interno rimarrebbe
moltissimo spazio verticale vuoto. Quindi, io ho deciso di montare l’LCD, i connettori input/output e i controlli sul pannello anteriore, collocare l’Arduino e il generatore DDS sul fondo della custodia e montare il jack per l’alimentazione esterna sul pannello posteriore. Questa soluzione lascia all’interno spazio sufficiente per un alimentatore o delle batterie (se dovessi decidere di includere una o entrambe queste cosa). La Figura 11-6 mostra il layout del pannello anteriore.
Figura 11-6 - Il layout del pannello anteriore del generatore di segnale.
Un’altra cosa da prendere in considerazione sono i pulsanti che si utilizzano come input dei controlli. Un modulo con una serie di piccoli pulsanti con tappi quadrati di basso profilo non è una cosa che si trova facilmente in commercio. Nella maggior parte dei casi, si tratta di assemblaggi personalizzati creati per un prodotti specifico. Dal momento che non abbiamo intenzione di avventurarci in una produzione di massa, non ha senso investire tempo e denaro per progettare e costruire un modulo personalizzato con una serie di 3 × 2 interruttori e quindi quello che finirà sul pannello anteriore potrà non assomigliare a quello che si vede nella Figura 11-6. Ma va bene lo stesso: funzionerà ugualmente, a prescindere quali pulsanti utilizzeremo.
Lo schema Osservando la Figura 11-4, possiamo vedere che sembra che si stiano utilizzando quasi tutti i pin disponibili su Arduino. Ed effettivamente è così, dal momento che non sono assegnati soltanto i pin A4 e A5. Con l’LCD, il DDS e gli interruttori di controllo collegati verranno utilizzati tutti i pin I/O digitali discreti e per l’I/O digitale dovranno essere utilizzati anche alcuni degli input analogici. Questo è mostrato nello schema della Figura 11-7.
Figura 11-7 - Lo schema del generatore di segnale.
La Tabella 11-2 elenca i pin di Arduino e le assegnazioni nel generatore di segnale. Qualsiasi ulteriore espansione dell’I/O dovrà essere effettuata utilizzando shield con un’interfaccia I2C per mezzo dei pin A4 e A5. Tabella 11-2 - L’utilizzo dei pin di Arduino nel generatore di segnale.
Pin
Funzione
Pin
Funzione
Pin
Funzione
D0
DDS FQ_UP
D7
LCD E
A0
Pulsante selezione
D1
DDS W_CLK
D8
Range + pulsante
A1
Pulsante modalità
D2
LCD D4
D9
Range – pulsante
A2
Porta di ingresso
D3
LCD D5
D10
Freq + pulsante
A3
Ingresso CV
D4
LCD D6
D11
Freq – pulsante
A4
SDA per espansione I/O
D5
LCD D7
D12
DDS RST
A5
SCL per espansione I/O
Il modulo DDS che voglio utilizzare per questo progetto è mostrato nella Figura 9-57 del Capitolo 9. Si trova presso diversi rivenditori, tra i quali DealeXtreme (http://bit.ly/dxad9850), per circa 8 $. La Figura 11-8 mostra il diagramma del pinout del modulo.
Figura 11-8 - Il pinout del modulo DDS AD9850.
L’AD9850 supporta sia l’interfaccia binaria parallela che seriale. In questa applicazione, l’Arduino comunicherà con il modulo DDS utilizzando la modalità dell’interfaccia seriale. Per i dati, questa modalità utilizza il pin D7 sul modulo DDS. Il modulo LCD ha 16 posizioni di pin, da collegare alla messa a terra, all’alimentazione e ai dati e ai segnali di controllo degli IC controller dell’LCD, che si trovano sul retro della PCB sotto gocce di di resina epossidica nera. La Figura 11-9 mostra le definizioni dei pin del modulo LCD.
Figura 11-9 - Il pinout del modulo LCD.
Il prototipo Questo progetto utilizza componenti pronti per l’uso e per sviluppare il software si rivela utile un prototipo costruito a partire dalle stesse shield e dagli stessi moduli. Se state aspettando che vi arrivino le parti, potete procedere con il software con un prototipo che funzioni in modo simile. Per questo progetto utilizzerò una configurazione di prova che consiste di un Arduino Uno montato su una base di legno, come mostra la Figura 11-10.
Figura 11-10 - Un prototipo di Arduino.
Nel prototipo utilizzo un Arduino Uno, una PCB con una serie 5 × 4 di pulsanti in miniatura che includono anche 8 LED, una coppia di estensori di terminali a vite, una shield di prototipazione con montato un modulo DDS e il modulo LCD che aggiungeremo nello strumento finale. I pulsanti serviranno per gli input dei controlli del generatore di segnale. I quattro relè mostrati nella Figura 11-10 non si utilizzano in questo progetto e quindi non sono collegati. Le connessioni con Arduino sono identiche a quelle mostrate nella Figura 11-7.
Gli input dei controlli e le modalità Sul pannello anteriore ci sono sei pulsanti. La Tabella 11-3 mostra come sono assegnati alle varie funzioni. Tabella 11-3 - Le funzioni dei pulsanti di controllo del generatore di segnale.
Pulsante
Modalità: Frequenza
Modalità: Gate
Modalità: CV
Freq
Inc frequency
Gate on
CV enable
Freq –
Dec frequency
Gate off
CV disable
Intervallo
Inc freq range
Gate
CV zero set
Range –
Dec freq range
Gate –
CV zero reset
Il generatore di segnale ha tre modalità di input dei controlli. Nella Tabella 11-3
possiamo vedere che in realtà ci sono 12 possibili input dei controlli, a seconda della modalità. Il pulsante Select non è mostrato, perché è utilizzato come se fosse il tasto “Invio”: premendo il pulsante Select, si uscirà dalla modalità di input per i controlli gate o CV e si riporterà lo strumento alla normale modalità di funzionamento di intervallo e frequenza. L’output delle forme d’onda è sempre attivo, a meno che non venga bloccato dalla modalità gate. La frequenza e l’intervallo possono essere alterati in qualsiasi momento quando lo strumento non si trova nella modalità gate. Premendo i pulsanti Freq + o Freq – e quindi rilasciandolo, si farà sì che la frequenza cambi di 1 Hz. Quando i pulsanti Freq + o Freq – sono mantenuti premuti, il valore cambia per incrementi (o decrementi) di 10, 100 o 1.000 (a seconda del valore corrente) finché il pulsante non viene rilasciato. L’output della frequenza del generatore è suddiviso in intervalli, ciascuna dei quali abbraccia 10.000 Hz. Quindi se l’intervallo 1 va da 0 a 9.999 Hz, l’intervallo 2 andrà da 10.000 a 19.999 Hz e così via. L’utilizzo dei controlli dell’intervallo non è obbligatorio. La ragione principale per includere questi controlli è permettere ai controlli Freq + e Freq – di regolare l’output in incrementi maneggevoli all’interno di un determinato intervallo. Altrimenti, l’utente dovrebbe premere i pulsanti Freq + o Freq – per un po’ per raggiungere la frequenza desiderata. La frequenza di output viene aggiornata continuamente e quindi non c’è bisogno di premere il pulsante Select. L’intervallo può essere un valore qualsiasi compreso tra 1 e 4.000. Se la frequenza è incrementata oltre il termine di un intervallo, il numero dell’intervallo si incrementa automaticamente. Se la frequenza viene decrementata al di sotto del valore minimo dell’intervallo attuale, il valore dell’intervallo viene decrementato di 1. L’intervallo si incrementerà o decrementerà automaticamente in passaggi di 10, 100 o 1.000, proprio come l’input dei controlli della frequenza. Le impostazioni di CV e gate si modificano passando lo strumento nella modalità di input dei controlli appropriata. Il pulsante Mode seleziona la modalità di input dei comandi e il pulsante Select rende attiva l’impostazione attuale e riporta lo strumento nella modalità operativa normale. Quando il gate è attivo, il generatore non produce nessun output finché la condizione di gate selezionata è presente sul la porta di ingresso. I pulsanti Freq + e Freq – si utilizzano per attivare o disattivare il gate. I pulsanti Range + e Range – selezionano la modalità gate sense: rispettivamente, active high o active low. Il CV (control voltage) input è una tensione analogica compresa tra 0 e 5 V DC, dove 2,5 V è il punto zero nominale (non si utilizzano tensioni negative). Nella modalità CV, i pulsanti Freq + e Freq – attivano o disattivano l’ingresso CV. Il punto zero può essere cambiato selezionando la modalità CV e premendo il pulsante Range +. Il pulsante Range – resetta il punto zero del CV sul valore predefinito di 2,5 V. Una volta attivato, l’ingresso CV è attivo finché non viene esplicitamente disattivato. Una tensione di input al di sopra del punto zero farà sì che la frequenza di output aumenti, mentre una tensione di input al di sotto punto zero farà sì che la frequenza di output si
riduca. Per impostare il punto zero, si applica la tensione desiderata all’ingresso CV e si preme il pulsante Range +. Disattivando l’ingresso CV non si altera l’impostazione del punto zero.
La visualizzazione dell’output Una grande sfida con qualcosa che utilizza un display minimo è scoprire come utilizzarlo in modo efficace per visualizzare le informazioni in una forma condensata. L’LCD che utilizziamo per il generatore di segnale ha due righe di posizioni indirizzabili con 16 caratteri ciascuna. La Figura 11-11 mostra come ho scelto di inserire le informazioni essenziali sul display durante il funzionamento.
Figura 11-11 - Il layout del display del generatore di segnale.
Quando il generatore di segnale si trova in una modalità qualsiasi che non sia l’output della frequenza, i due punti che seguono la lettera relativa alla modalità lampeggiano. Quindi, se si trova nella modalità CV, lampeggiano i due punti dopo il carattere C e quelli dopo il carattere G lampeggiano quando si trova nella modalità gate. Premendo l’interruttore Mode, si passa ciclicamente e ripetutamente tra Gate, CV e input dei controlli off (funzionamento normale). Le funzioni C e G possono essere alterate soltanto quando è attiva la modalità di controllo associata. Una volta mostrato il valore desiderato, il pulsante Select imposta l’output sulla configurazione visualizzata e lo strumento riprende il funzionamento normale. Il campo G (gate) mostrerà X, +, oppure –, a seconda dello stato della funzione gate. Il simbolo + significa che il gate è attivo su un input high, mentre il simbolo – significa che il gate risponderà a un input low. X significa che la funzione gate è disattivata. Le impostazioni del gate diventeranno attive quando si premerà il pulsante Select. Il campo C (CV) mosterà X, 0, +, oppure –. Mostrerà + se la funzione CV è attiva e la tensione di controllo dell’input è maggiore del punto zero, - se CV è attiva e la tensione di controllo è inferiore al punto zero e 0 se CV è attiva e la tensione di controllo è uguale al punto zero. I simboli 0, + e – vengono aggiornati in tempo reale quando viene attivato
l’ingresso CV. X significa che l’ingresso CV è disattivato. Le impostazioni del CV diventeranno attive quando si premerà il pulsante Select. In molti sensi, questo è un ritorno ai tempi quando molti dispositivi erano dotati di display piccoli. Prima dell’avvento dei display LCD e TFT ad alta risoluzione, si vedevano spesso display piccoli come questo, se mai se ne utilizzava uno. Prima dell’introduzione dei display LED alfanumerici, questo lo si sarebbe fatto utilizzando soltanto numerali e interpretare alcuni di questi vecchi display era sicuramente difficile. Per fortuna, adesso possiamo comprare piccoli ed economici componenti LCD alfanumerici, ma è ancora necessaria un po’ di creatività per il layout dei dati e un certo grado di interpretazione.
Il modulo DDS Il modulo DDS AD9850 è montato su una shield di prototipazione, come mostrato nella Figura 11-12. Questo è opzionale ed è possibile montarlo semplicemente sul fondo della custodia e utilizzare fili per collegarlo. Io, però, vi consiglio la shield, perché fornisce una base robusta per il modulo e permette di utilizzare terminali a vite. Questo è un modo molto più ordinato di creare le connessioni che non saldare ed è molto più affidabile che collegare ponticelli.
Figura 11-12 - La shield di prototipazione del modulo DDS.
Tutta la shield DDS è formata dalle parti elencate nella Tabella 11-4. Tabella 11-4 - L’elenco delle parti della shield di prototipazione DDS.
Quantità
Descrizione
1
Shield di prototipazione, Adafruit #51 o equivalente
1
Morsettiera a vite da 8 posizioni e 0,1 pollici (2,54 mm)
1
Pin socket header da 6 posizioni
1
Modulo DDS AD9850
Gli input del modulo DDS sono collegati al pin socket da sei posizioni e gli output sono collegati alla morsettiera da otto posizioni. L’alimentazione e la messa a terra sono fornite dalla shield di prototipazione. I LED per adesso non sono utilizzati, ma uno può essere collegato all’alimentazione e l’altro all’input D7 (D13 sull’Arduino). La Figura 1113 mostra come i vari segnali e le varie linee dei moduli DDS si collegano sulla shield di prototipazione.
Figura 11-13 - I segnali della shield di prototipazione DDS.
La morsettiera della PCB e il pin socket headerda sei posizioni si collegano sulla parte inferiore della shield di prototipazione. Io ho utilizzato un filo da 28 AWG, ma va bene qualsiasi filo tra i 24 e i 32 AWG. Per le connessioni tra i pin del modulo e la morsettiera, non ho utilizzato cavi schermati, ma può valere la pena farlo, specialmente
ad alte frequenze. Per gli input dei controlli del DDS avrei preferito non utilizzare un socket header, ma, vista la mancanza di spazio sulla shield di prototipazione, non rimanevano molte alternative. Nell’assemblaggio finale, ho utilizzato alcuni jumper esistenti e ho tagliato le estremità che sarebbero andate nei terminali a vite per i segnali di controllo di Arduino. Nella versione finale, questi fili verranno fissati al socket header con un po’ di gomma siliconica trasparente.
Il software Il software del generatore di segnale è strutturato nel modo convenzionale per le applicazioni di Arduino, con una funzione setup() e una funzione loop(). La funzione setup() gestisce le modalità dei pin I/O e altre configurazioni, mentre la funzione loop() gestisce gli input dei controlli e gli output del segnale. Il generatore di segnale si discosta da uno sketch convenzionale per il modo nel quale è organizzato. È composto di diversi file sorgente (sei in tutto) con file include (cioè, “header”) associati.
Aumento di complessità e interfaccia Anche se dal punto di vista concettuale questo progetto può sembrare semplice, il software presenta un grado sorprendentemente alto di complessità. Perché? Per via dell’interfaccia di controllo. Gli sviluppatori e gli ingegneri software che lavorano regolarmente con software orientato alla GUI vi hanno molta familiarità, dal momento che spesso il 70% o più del codice è dedicato soltanto alla gestione della GUI. Questo è anche il motivo per il quale le utility a linea di comando che si trovano sui sistemi Unix o Linux tendono a essere funzionalmente potenti e allo stesso tempo molto compatte: non c’è il peso di una GUI con la quale lottare, ma soltanto l’interfaccia a linea di comando. Anche le applicazioni con microcontroller vedono aumentare l’esperienza dell’interfaccia quando deve essere implementato del codice che permetta al sistema di interagire con un utente umano. Gli umani tendono a essere lenti, disattenti e non molto bravi a ricordare e utilizzare codici di comando compatto o a interpretare risposte criptiche. Per questo, alcune parti (spesso molte) del software della MCU devono essere dedicate alla creazione di un’interfaccia utente con la quale possa interagire in modo effettivo un umano normale. In alcuni design, questo si risolve eseguendo l’interfaccia utente su un sistema host separato dove cose come la memoria limitata e velocità ridotte del clock della CPU non sono un problema e quindi utilizzando un’ interfaccia compatta ed efficiente per le macchine per passare comandi, parametri e dati di stato tra l’host e la MCU. Con questo progetto, questo è sempre stato un approccio possibile, ma l’inconveniente è che limita la portabilità del dispositivo della MCU, perché dipenderà sempre dal sistema host con l’interfaccia utente. In alcune applicazioni, questo non è un grosso problema, come nel caso di dispositivi di controllo e rilevamento in remoto che si trovano installati in luoghi permanenti, collegati a un computer di controllo centrale. Tuttavia, il generatore di segnale che stiamo costruendo qui è pensato per essere uno strumento di test portatile e quindi ha bisogno di disporre almeno di un’interfaccia utente essenziale incorporata nel suo design. La sfida quindi diventa trovare un modo per ottenere il massimo della funzionalità possibile con un numero limitato di input dei controlli, inserire la massima quantità di informazioni utili in un display decisamente limitato e fare tutto ciò senza interferire con le operazioni principali dello strumento o senza consumare troppa della memoria flash disponibile che il software non riesce a caricare nella MCU.
Il software per controllare il DDS in realtà non fa altro che leggere la porta di ingresso o l’ingresso CV e quindi scrivere i giusti dati di controllo sull’IC DDS. La parte difficile è
come mappare gli input dei controlli in modo che ci permettano di controllare come e quando avvengono queste azioni. Come nel caso di qualsiasi altro dispositivo dotato di microcontroller, è il software che offre la funzionalità desiderata. Senza il software, non è altro che una massa di plastica, fili, schede a circuito e un po’ di silicio.
L’organizzazione del codice sorgente Il codice del generatore di segnale è contenuto in diversi file sorgente. Quando l’IDE di Arduino apre il file principale, sig_gen.ino, apre anche gli altri file che si trovano nella stessa directory. I file secondari sono collocati in schede dell’IDE, come mostra la Figura 11-14.
Figura 11-14 - L’IDE di Arduino dopo aver caricato lo sketch sig_gen.ino.
Il codice del generatore di segnale è strutturato in modo tale che le variabili globali si trovino in un modulo di compilazione separato, sig_gen_gv.cpp. Anche l’LCD, gli input dei controlli, le funzioni CV (control voltage) e gate si trovano in moduli separati. La Tabella 11-5 elenca i moduli sorgente e le loro rispettive funzioni. Tabella 11-5 - I moduli del codice sorgente del generatore di segnale.
Modulo
Funzione
sig_gen.ino
Modulo principale che contiene setup() e
sig_gen.h
Definizioni delle costanti (dichiarazioni
loop()
#define)
sig_gen_control.cpp
Elaborazione dell’input dei pulsanti di controllo
sig_gen_control.h
File include
sig_gen_cv.cpp
Elaborazione dell’ingresso CV
sig_gen_cv.h
File include
sig_gen_gate.cpp
Elaborazione della porta di ingresso
sig_gen_gate.h
File include
sig_gen_gv.cpp
Variabili globali
sig_gen_gv.h
File include
sig_gen_lcd.cpp
Funzioni LCD
sig_gen_lcd.h
File include
NOTA Notate che gli oggetti LCD e DDS si istanziano utilizzando l’operatore C++ new nel file sig_gen_gv.cpp. Questo è possibile perché le variabili “ancora” degli oggetti, lcd e ddsdev, sono definite nel modulo delle variabili globali ed esportate in sig_gen_gv.h. Perché questo funzioni, il modulo principale deve contenere le dichiarazioni include di LiquidCrystal.h e DDS.h e le stesse dichiarazioni include devono apparire anche nel file delle variabili globali. Per via di un’irregolarità nel modo nel quale l’IDE di Arduino gestisce le dichiarazioni di scoping e include, tutti i riferimenti a una libreria esterna inclusi nel file di una scheda devono essere inclusi anche nel file principale. Notate anche che i moduli ausiliari contengono la dichiarazione #include "Arduino.h" per permettersi l’uno all’altro di accedere all’ambiente di Arduino. L’operatore new è descritto nel riquadro “Istanziare oggetti di classe con new” a pagina 103 nel Capitolo 5.
La descrizione del software Il codice del generatore di segnale è abbastanza lungo e quindi, anziché provare a elencarlo tutto qui, mi concentrerò sulle sezioni principali e sui alcuni dei punti più importanti, utilizzando diagrammi di flusso e porzioni di codice. Vi suggerisco di scaricarvi il codice sorgente da GitHub (https://github.com/ardnut) e di esaminarlo mentre leggete questo testo. Il modulo sig_gen.h è una raccolta delle costanti #define utilizzate nel programma. Le dichiarazioni #define permettono di fare riferimento a valori evitando di avere “numeri crudi” che se ne vanno a spasso per il codice. Questo rende più facile cambiare qualcosa, come una posizione sull’LCD o un ritardo di tempo utilizzato in diversi punti, senza dover cercare ogni istanza del valore crudo. Applicando le modifiche manualmente, è facile mancarne una o due, mentre con il file #define possiamo assicurarci che tutte assumeranno il valore desiderato. Possiamo, naturalmente, utilizzare anche la dichiarazione C++ const, ma, come abbiamo visto nel Capitolo 5, le dichiarazioni #define consumano meno memoria. Il file sig_gen_gv.cpp contiene la dichiarazione delle variabili globali. I contenuti di sig_gen_gv.cpp sono mostrati nell’Esempio 11-1. Dal momento che sig_gen_gv.cpp è
un codice sorgente eseguibile, può contenere dichiarazioni di inizializzazione. Esempio 11-1 - Le variabili globali.
Notate che sono presentati due metodi diversi di creare oggetti globali. Il primo utilizza la dichiarazione new e il secondo utilizza l’assegnazione dei puntatori. Dal punto di vista della funzionalità, il risultato finale è effettivamente lo stesso, ma l’utilizzo della memoria è leggermente diverso. Il file include sig_gen_gv.h contiene le dichiarazioni di esportazione. La dichiarazione export dice al compilatore che queste variabili saranno utilizzate da altri moduli e quindi, quando viene compilato un modulo che fa riferimento a una variabile dichiarata nel file sig_gen_gv.h, vengono creati dei segnaposto. Il linker metterà tutto insieme quando verrà costruita l’immagine eseguibile finale. L’output del generatore di segnale è controllato da una serie di variabili globali che contengono la frequenza e i valori di intervallo correnti, oltre allo stato delle funzioni gate e CV. Nei sistemi integrati, questo è un approccio comune, specialmente in situazioni dove è disponibile moltissima RAM dove salvare grandi quantità di dati nello stack. Anziché passare moltissimi argomenti alle funzioni, si utilizzano variabili globali come un tipo di spazio di memoria condiviso. La chiave per utilizzare le variabili globali in modo efficace è applicare il più possibile la regola “scritto da uno, letto da molti”. In un piccolo sistema con soltanto un programma attivo, non è molto frequente la situazione nella quale una variabile è modificata da due processi contemporaneamente, ma in applicazioni multithreaded questa è una possibilità reale. Dal momento che stiamo utilizzando la struttura convenzionale setup() e loop() proposta dall’IDE di Arduino, la prima funzione importante che ci interessa è start(). La Figura 11-15 mostra un diagramma di flusso dettagliato di setup().
Figura 11-15 - Il diagramma di flusso della funzione setup().
La funzione setup() (Esempio 11-2) è semplice. Inizializza l’oggetto LCD, mostra un messaggio di avvio, inizializza gli input digitali dei pulsanti di controllo, fa apparire “Ready” sull’LCD e infine scrive i campi relativi alla frequenza, al gate, all’intervallo e al CV sull’LCD. Questi non cambieranno per il resto del tempo durante il quale il generatore di segnale rimarrà attivo. Esempio 11-2 - La funzione setup() del generatore di segnale.
Nelle funzioni TitleDisp1() e TitleDisp2() si utilizzano le chiamate a un ritardo per rallentare le cose, in modo che il testo di avvio non lampeggi troppo rapidamente e possa essere letto dall’utente. La funzione InitLCDFields(), che si trova nel file sig_gen_lcd.cpp e viene chiamata da setup(), scrive i campi statici sull’LCD dopo che è avvenuta l’accensione. Può essere chiamata diverse volte da diversi punti del codice, secondo necessità. Il ciclo principale del software esegue quattro passaggi principali: 1. Controlla gli input dei pulsanti di controllo. 2. Controlla l’ingresso CV (se attivato). 3. Controlla la porta di ingresso (se attivato). 4. Aggiorna la frequenza di output. I passaggi 1 e 2 comportano l’analisi delle stringhe dei comandi provenienti dal PC host e la decodifica dei pulsanti di controllo in base alla modalità corrente. Questa à la parte più complessa del software. I passaggi 2 e 3 si limitano a controllare gli input per determinare che cosa cambia nell’output, se avviene qualche modifica. Il passaggio 4 scrive i dati di controllo sull’AD9850 dopo aver eseguito un semplice calcolo. La Figura 11-16 mostra un diagramma di flusso ad alto livello di loop().
Figura 11-16 - Un diagramma di flusso ad alto livello del generatore di segnale (funzione loop()).
Il codice sorgente della funzione loop(), elencato nell’Esempio 11-3, appare semplice perché tutte le funzionalità si trovano nei moduli ausiliari. Quando viene chiamata ciascuna delle funzioni, imposta o legge le variabili globali. Esempio 11-3 - La funzione loop() del generatore di segnale.
L’output dei controlli sul modulo DDS è l’ultima cosa che il ciclo principale esegue prima di applicare un ritardo di MAIN_DLY millisecondi e ripartire. La frequenza di output, fval, viene modificata dall’ingresso CV per mezzo di RunCV() se CV è attivo e può essere impostata su on oppure su off dalla funzione RunGate() se quella modalità operativa è attiva. I dati del DDS vengono scritti dopo un numero DDS_LOAD_GO di iterazioni di loop() per dare al modulo il tempo di elaborare i dati dei controlli provenienti da Arduino. L’intervallo di aggiornamento della frequenza è uguale a DDS_LOAD_GO volte MAIN_DLY millisecondi. Se modifichiamo il valore di MAIN_DLY possiamo dover modificare anche DDS_LOAD_GO. Il file sorgente più lungo è sig_gen_control.cpp. Questo contiene il codice per rilevare l’attività degli interruttori degli input dei controlli, per eseguire il debounce degli input degli interruttori, per determinare se un pulsante è tenuto premuto dall’utente e impostare la modalità degli input dei controlli Dal punto di vista elettrico, gli interruttori tendono a rivelarsi rumorosi. Per compensare questo, il generatore di segnale incorpora una semplice funzione di debounce, come mostra l’Esempio 11-4. Esempio 11-4 - La funzione di debounce.
L’idea che sta dietro debounce() è determinare se un interruttore ha mantenuto lo stesso stato tra due campioni di input. In caso affermativo, l’interruttore si considera ancora in quello stato, altrimenti significa che si è verificato un errore. L’intervallo di tempo del test, DBDLY, è definito in sig_gen.h e ha un valore iniziale pari a 10 ms. Questo può essere incrementato per migliorare l’affidabilità del debounce, ma se lo si aumenta troppo gli input dei controlli possono cominciare a rispondere con lentezza, conseguenza che può non essere desiderabile. La funzione readControls() analizza i sei interruttori dei pulsanti di input. Se è stato premuto un interruttore, incrementa il valore di un conteggio ogni volta che loop() chiama readControls(). Se il conteggio supera un valore predeterminato (definito come HOLD_CNT in sig-gen.h), l’input viene contrassegnato come ancora premuto impostando la variabile globale btnhold su true. Ricordate che loop() viene eseguito ogni MAIN_DLY millisecondi. La funzione getFreq() gestisce la frequenza. Incrementa o decrementa automaticamente la frequenza in passaggi di 10, 100 o 1.000 Hertz. Anche il valore dell’intervallo viene regolato automaticamente quando la frequenza supera un limite impostato su RSTEP Hertz. La funzione SetMode() cambia la modalità di controllo corrente dello strumento se il pulsante Mode viene premuto e rilevato da readControls(). Passa in rassegna le tre modalità di controllo (normale, gate e CV) finché il pulsante rimane premuto. Il comportamento delle modalità gate e CV può essere alterato soltanto quando è attiva la modalità corrispondente. Il codice sorgente completo del generatore di segnale è disponibile su GitHub (https://github.com/ardnut), commentato e auspicabilmente facile da capire.
La libreria DDS Con il codice sorgente del generatore di segnale, è stata inclusa una semplice libreria per il modulo DDS. Per installare la libreria DDS basta creare una directory di nome DDS nella propria directory sketchbook/libraries e inserirvi DDS.cpp e DDS.h. La libreria DDS apparirà nella casella combinata delle librerie dopo il riavvio dell’IDE (o
immediatamente nelle versioni più recenti dell’IDE). Potete notare che tra i file della sottodirectory della libreria DDS non c’è nessun README, né nessun keywords.txt. Questa classe è così semplice che non ne ho visto la necessità. La libreria DDS utilizzata con il generatore di segnale illustra alcuni dei concetti della creazione di librerie personalizzate che sono stati presentati nel Capitolo 5. Si tratta di una classe semplice, che gestisce i calcoli necessari per creare il data word di controllo utilizzato dall’AD9850. Il file DDS.h, mostrato nell’Esempio 11-5, contiene la definizione della classe. Esempio 11-5 - La classe DDS.
Dopo che l’oggetto DDS è stato istanziato, se vogliamo migliorare la precisione del generatore di segnale possiamo passarvi un coefficiente di calibrazione. Per vedere come si calcola questo valore, potete consultare la scheda tecnica dell’AD9850. In questa classe, presenta semplicemente il valore predefinito 0. Oltre al costruttore dell’oggetto e alla funzione calibrate(), l’unico altro metodo utilizzato dal codice al di fuori della classe è la funzione setFrequency(). La frequenza è espressa in Hertz. La word di controllo calcolata viene spostata sull’IC DDS un bit alla volta.
I test Dando per scontato che il prototipo sia collegato correttamente, dobbiamo riuscire a compilare e a caricare il software su Arduino Uno. All’avvio, il display mostra “DDS Signal Gen” e “Initializing”, seguito da “Ready” e quindi dai campi relativi ai dati. Possiamo regolare i tempi di ritardo per fare in modo che il testo di avvio rimanga sul display più a lungo oppure eliminarlo completamente. Siete liberi di scegliere. SUGGERIMENTO Quando il generatore di segnale è collegato come mostrato nella Figura 11-7, si può utilizzare la
libreria Serial. La libreria assume il controllo dei pin Rx e Tx (D0 e D1, rispettivamente) e li rende high. Questo confonde il DDS 9850 e non genera nessun output. La libreria Serial va bene per il debug degli input dei controlli, che è quello che ho fatto, ma non deve essere istanziata quando è collegato il DDS. Potete sempre modificare le assegnazioni dei pin analogici e digitali in modo da utilizzare A4 e A5 per gli input degli interruttori dei controlli e liberare D0 e D1 per l’I/O seriale, ma in questo progetto io non ho visto la necessità di farlo. L’interfaccia USB funziona bene per caricare nuovo software su Arduino, se necessario, anche con il modulo DDS collegato.
Il codice è preconfigurato in modo che generi un output di 1.000 Hz quando viene alimentato il prototipo. Questo può essere un valore qualsiasi a vostra scelta che ricada all’interno dell’intervallo dell’AD9850, ma io ho scelto 1.000 perché è un valore che posso vedere facilmente con un oscilloscopio. NOTA Per controllare l’output del DDS, avrete bisogno di un oscilloscopio di qualche tipo e più veloce è meglio è. Quelli come gli economici oscilloscopi digitali Nano, da uno o due canali, di Seeed, che assomigliano a lettori MP3, in genere non vanno oltre circa 1 MHz. Se volete controllare la frequenza più alta dell’intervallo dell’IC DDS, vi serve qualcosa con un’ampiezza di banda di almeno 100 MHz. Io tengo sempre sotto mano il mio piccolo Seeed DSO Nano per misurare i circuiti lenti, ma quando devo lavorare oltre 1 MHz mi armo di qualcosa di più robusto.
La prima cosa da controllare è l’output a onde sinusoidali. Nella Figura 11-17 è mostrata l’onda sinusoidale da 1.000 Hz, che dovrebbe essere circa 1 V P-P. Il prototipo non è dotato dei controlli di livello dell’output che aggiungeremo nell’unità finale e quindi, se non vedete l’onda sinusoidale, dovete scollegare l’unità e ricontrollare le connessioni.
Figura 11-17 - Un output a onde sinusoidale predefinita da 1 kHz.
L’output a onde quadre avrà la stessa frequenza di quello a onde sinusoidali, con un’ampiezza di circa 5 V P-P (in realtà, qualunque V+ sia). L’output si presenterà come quello della Figura 11-18.
Figura 11-18 - Un output a onde quadre da 1 kHz.
Se sono presenti entrambi gli output, i test possono procedere con gli input dei controlli. Gli input di frequenza e intervallo possono essere testati innanzitutto premendo i pulsanti Freq + e Freq –. La frequenza sul display deve cambiare di 1 Hz a ogni pressione del pulsante. Adesso dobbiamo tenere premuto il pulsante Freq +. La frequenza deve incrementarsi prima di 1, poi di 10, poi di 100 e infine di 1.000. Ci fermiamo a circa 15.000 e controlliamo l’output. Notate che il valore dell’intervallo si incrementa automaticamente quando la frequenza va oltre 9.999. Ripetiamo il tutto con il pulsante Freq –. Il valore dell’intervallo si riduce man mano che decresce la frequenza. Se premiamo il pulsante Range +, la frequenza si incrementa di 10.000 a ogni pressione del pulsante. Cambiamo l’intervallo su un valore pari a 4 e osserviamo l’output. Deve essere di circa 40 kHz. Premiamo il pulsante Range – e osserviamo il display. La frequenza deve ridursi di 10.000 per ogni decremento nel valore dell’intervallo. Premiamo il pulsante Mode e teniamolo momentaneamente premuto finché i due punti accanto al simbolo G non cominciano a lampeggiare. Adesso premiamo i pulsanti Freq + e Freq – per attivare e disattivare la porta di ingresso. Premiamo i pulsanti Range + e Range – per cambiare lo stato dell’input sense. Deve alternare tra + e –. Premiamo il pulsante Select per tornare al funzionamento normale. Quando il gate è attivo e non c’è nessuna porta di ingresso, l’output deve cessare. Selezioniamo la modalità di input – (active low) e osserviamo che l’output diventa attivo ogni volta che un jumper è collegato dalla porta di ingresso (A2 sulla Uno) alla messa a terra. Quando ci troviamo nella modalità di input + (active high), l’output viene attivato ogni volta che il jumper è collegato a una sorgente di tensione positiva, ma cessa quando l’input A2 è messo a terra. Disattiviamo la porta di ingresso entrando nella modalità di controllo del gate e utilizzando il pulsante Freq – per disattivare il funzionamento del gate. Per testare l’ingresso CV (A3 su Arduino), avremo bisogno di un’alimentazione variabile oppure di un alimentatore da 5 V e di un potenziometro da 10K e anche di un DMM, mostrato nella Figura 11-19. Se il vostro oscilloscopio non è dotato di una funzione di
visualizzazione della frequenza (come la maggior parte dei moderni strumenti DSO), potete utilizzare un contatore di frequenza di qualche tipo.
Figura 11-19 - La configurazione della tensione degli input.
Attiviamo il CV utilizzando il pulsante Mode, ma non impostiamo il punto zero (lasciamolo sul valore intermedio predefinito di circa 2,5 V). Premiamo il pulsante Select per tornare al funzionamento normale. Applichiamo una tensione compresa tra 0 e 5 V, mentre osserviamo l’output della frequenza. La frequenza deve decrescere quando l’ingresso CV è inferiore a 2,5 V e aumentare quando è maggiore di 2,5 V. Osserviamo anche la polarità del CV guardando l’indicazione di polarità + e –. Impostare il CV manualmente sul punto zero è quasi impossibile, ma possiamo vedere il display mostrare brevemente uno 0 quando l’input passa il valore zero. Adesso regoliamo la tensione del CV per circa 2 V sul DMM. Passiamo lo strumento nella modalità CV, attiviamo l’ingresso CV e premiamo il pulsante Range + per impostare un nuovo valore zero. Il simbolo della polarità adesso deve essere 0 e tale deve restare finché la tensione dell’input non cambia. Cambiamo la tensione dell’input e osserviamo che la frequenza di output aumenta o diminuisce man mano che l’ingresso CV va al di sopra o al di sotto del nuovo valore del punto zero. Al termine, utilizziamo i pulsanti Mode e Freq – per disattivare la funzione ingresso CV. ATTENZIONE Non applicate più di 5 V o una tensione negativa all’ingresso CV. Questo circuito è un prototipo e non ha nessuna protezione degli input. Superare l’intervallo di input dell’ADC della MCU AVR può distruggerlo. Quando assembleremo l’unità finale, la doteremo di un semplice circuito di protezione degli input.
Questo conclude i test funzionali essenziali. Se tutto funziona correttamente, adesso è
un buon momento per fare esperimenti con il generatore di segnale per vedere come risponde agli input dei controlli. È anche un buon momento per impostare il ciclo di lavoro delle onde quadre. Sulla PCB del modulo DDS, sull’estremità opposta rispetto a quella del modulo oscillatore argentato, c’è un piccolo potenziometro. Impostiamone la frequenza su circa 10 kHz e, utilizzando un oscilloscopio, regoliamo l’onda quadra in modo che le porzioni “on” e “off ” abbiamo la stessa durata. Nell’unità finale possiamo decidere di dissaldare il potenziometro della PCB e di sostituirlo con un controllo montato sul pannello sulla parte anteriore o posteriore del generatore di segnale.
L’assemblaggio finale Se decidete di utilizzare la shield di prototipazione per il modulo DDS, vi suggerisco una serie di estensori dei terminali a vite, come quelli mostrati in “Shield adattatori” a pagina 271 nel Capitolo 8. Questi non soltanto offrono collegamenti affidabili per i fili, ma sollevano anche la shield DDS sulla scheda Arduino. In questo modo, rimane dello spazio per quando dovete accedere al connettore ICSP. Potete anche utilizzare una shield con terminali a vite, come il kit mostrato in “Ridurre il costo” a pagina 468.
Le resistenze pull-up Sei resistenze da 2,2K montate in una parte della scheda perforata del prototipo servono come pull-up per i sei interruttori dei pulsanti. Anche se la MCU AVR ha un certo grado di funzionalità di pull-up, la serie di resistenze assicurano che ci sarà una tensione positiva per lavorare con gli interruttori. Significa anche che gli input degli interruttori sono active low (input 0 V = on). Dal punto di vista elettrico, il modulo pull-up è molto semplice, come si può vedere nello schema mostrato nella Figura 11-20. Le sei resistenze sono collegate sulle linee del segnale di ciascun interruttore degli input dei controlli e la connessione comune di tutte le resistenze è collegata a +5 V DC.
Figura 11-20 - Lo schema delle resistenze pull-up degli input dei controlli.
La scheda pull-up completa è mostrata nella Figura 11-21. L’utilizzo delle morsettiere da 0,1 pollici consente collegamenti facili e connessioni affidabili. Inoltre, la Figura 11-21 mostra il modulo di protezione degli input e l’Arduino montato con la shield di prototipazione DDS. A questo punto, sono stati collegati soltanto +5 V e la messa a terra.
Figura 11-21 - La serie di pull-up e il modulo di protezione degli input.
La protezione degli input Per costruire un semplice circuito di protezione degli input mostrato nella Figura 11-22, ho utilizzato un piccolo modulo a scheda perforata. L’idea è impedire a qualsiasi tensione superiore a +5 V DC o inferiore a 0 V (cioè, negativo) di entrare nelle porte di
ingresso o CV.
Figura 11-22 - Lo schema del circuito esterno di protezione degli input dei controlli.
Le resistenze da 470 ohm per limitare la tensione in serie con gli input possono produrre un leggero abbassamento della tensione che appare sull’input dell’ADC dell’AVR, ma, dal momento che la porta si comporta come un input binario e che il CV è un input relativo, in realtà non importa. I valori delle resistenze possono essere perfino aumentati, se vi preoccupa il fatto che qualcuno dei diodi passi troppa corrente in una situazione di sovratensione o sottotensione. Il modulo di protezione completo è stato mostrato nella Figura 11-21. Qui sono state utilizzate anche le morsettiere della PCB.
I componenti dello chassis Il software è pronto, tutte le parti sono a portata di mano e adesso è venuto il momento di mettere tutto all’interno della custodia. La parte più complicata è fare bene i fori nel pannello anteriore. Per farlo, ho perforato e tagliato sulla parte posteriore del pannello anteriore. Questo aiuta a tenere le cose ordinate e, se si producono graffi o tagli perdendo il controllo di uno strumento, nessuno se ne accorgerà mai. Quindi, dobbiamo montare l’Arduino e il modulo DDS sul fondo della custodia, seguiti dai connettori USB e DC sul pannello posteriore. Infine viene il compito di collegare i controlli, i connettori e i moduli l’uno all’altro nel modo corretto.
Prima si perforano e si tagliano i pannelli anteriore e posteriore. Il pannello anteriore ha bisogno di un foro rettangolare per l’LCD e di fori per gli interruttori e i connettori. Il pannello posteriore ha un connettore di alimentazione DC montato sul pannello e un potenziometro per il contrasto dell’LCD. L’USB di Arduino non è collegato al pannello posteriore. Al connettore USB di Arduino si può accedere dopo aver rimosso il coperchio della custodia. La Figura 11-23 mostra i fori sul pannello anteriore mentre li si sta aprendo con un piccolo trapano a colonna, anche se se ne può utilizzare uno di dimensioni normali. Potete anche utilizzare un trapano a mano, ma dovete fare attenzione a segnare dove devono andare i fori, prendervela con calma e innanzitutto aprire dei piccoli fori preliminari. Io ho trasferito le dimensioni del disegno (Figura 11-24) con un righello e delle pinze e poi ho fatto i fori preliminari con un utensile rotante e una piccola punta di trapano.
Figura 11-23 - Praticare i fori nel pannello anteriore.
Figura 11-24 - Il layout dei fori sul pannello anteriore del generatore di segnale.
La Figura 11-24 mostra il modello dei fori utilizzato per il pannello anteriore del generatore di segnale. Per montare il modulo LCD, ho specificato fori #4 (2,79 mm), ma potete utilizzare fori con un diametro inferiore, se sono posizionati con precisione. Il pannello posteriore ha solo un connettore di alimentazione DC cilindrico e un potenziometro per il contrasto dell’LCD e questi possono essere montati come meglio credete. Anche se può non essere necessario prendersi la briga di creare disegni dettagliati come quelli che sono stati preparati per questo progetto, valgono per molto tempo. I disegni della progettazione e della produzione sono registrazioni di quello che è stato fatto e assicurano che, se mai dovesse sorgere la necessità di costruire altri generatori di segnale, non si dovrà ripetere nessuno dei lavori di design a meno che non si applichino modifiche drastiche. L’Arduino Uno e la shield di prototipazione DDS sono montati sul fondo della custodia, insieme alla serie di resistenze pull-up e al modulo di protezione degli input. Le posizioni esatte non sono particolarmente importanti, ma l’Arduino non deve essere montato vicino al pannello anteriore per aiutare a tenere i cavi ordinati. La Figura 11-21 mostra i componenti interni montanti e pronti per essere collegati ai componenti sul pannello anteriore. Dopo aver montato i componenti interni e aver aperto i fori nel pannello anteriore, il passaggio logico seguente è montare i vari controlli e il modulo display LCD sul pannello anteriore. Non dobbiamo dimenticarci di etichettare i controlli e i connettori. SUGGERIMENTO Se prevedete di utilizzare un’etichettatrice, potete stampare e applicare le varie etichette prima o dopo aver montato i controlli. Tuttavia, se prevedete di utilizzare trasferelli o di dipingere le lettere sul pannello in qualche modo (magari con una serigrafia), vi conviene farlo prima di montare le parti. Inoltre, quando utilizzate un’etichettatrice dovete assicurarvi di disporre del nastro appropriato per il dispositivo. Per esempio, alcuni modelli non sono dotati di nastro “bianco su nero”. Dovete assicurarvi di trovare il nastro del quale avete bisogno, oppure dovete accontentarvi delle opzioni disponibili, prima di decidere di utilizzare l’etichettatrice. Io ho utilizzato una stampante laser e etichette adesive per stampare le lettere (bianco su nero) e poi ho ritagliato ciascuna di esse e le ho appiccicate sul pannello anteriore.
È sorprendente quanto velocemente la custodia può cominciare a riempirsi una volta che le parti sono al loro posto e che i fili corrono tra i vari componenti. La Figura 11-25 mostra come si presenta la parte interna del generatore di segnale appena prima di chiuderlo con il coperchio. Notate che non mi sono preoccupato di aggiungere una manopola sul potenziometro del contrasto montato sul pannello posteriore.
Figura 11-25 - Il generatore di segnale completo dal punto di vista elettrico.
NOTA Aspettate un attimo a montare il coperchio. Lasciate lo strumento aperto finché non avete completato il test finale. Nessuno è perfetto e possono verificarsi piccoli errori. Se l’unità è aperta, raggiungere e aggiustare un terminale allentato o ricollegare un cavo è molto più facile.
Il modulo LCD si monta utilizzando quattro distanziatori di nylon con sotto i dadi. Io ho saldato degli standard socket header standard sovrapponibili sulla PCB dell’LCD da davanti e poi ho ritagliato i terminali sul retro di circa 1/4 di pollice (6,5 mm), per permettere ai socket header di essere premute sui pin. I fili saldati sugli header pin e protetti dal termorestringente producono connettori fatti in casa decenti per il modulo LCD. Potete vedere i connettori dell’LCD nella Figura 11-25. Per ordinare i cavi, ho utilizzato delle fascette di nylon e le morsettiere della PCB hanno reso facilissimo creare le connessioni. L’unica parte che è stata leggermente difficile è stato trovare un modo di trasformare in connettore l’input dell’alimentazione DC e il controllo del contrasto dell’LCD montati sul pannello posteriore. Alla fine, sono ricorso a una morsettiera da sei posizioni con viti #6 (da 3,3 mm) e terminali crimpati.
L’alimentazione Il generatore di segnale include un connettore cilindrico sul pannello posteriore per l’input
dell’alimentazione DC. Oltre al jack DC, ho acquistato anche le prese corrispondenti. Questo significa che ho potuto selezionare un trasformatore da parete (adattatore DC) con un output di tensione adatto, collegare la presa e sapere che corrispondeva correttamente al connettore dell’alimentazione. La tensione DC del connettore posteriore è condotta a una morsettiera, quindi all’interruttore dell’alimentazione sul pannello anteriore e infine a un connettore DC che si inserisce nella scheda Uno scheda. Non ci sono fuse, dal momento che l’alimentazione DC non è condotta da nessuna parte dove potrebbe trovare un percorso esterno diretto alla messa a terra, ma aggiungerne uno non sarebbe difficile. I ragazzi di Arduino, per un Arduino senza USB collegato, consigliano di utilizzare un adattatore da 9 a 12 V DC. Con un adattatore da 5 V DC, c’è un forte calo nel regolatore di tensione interno sulla PCB di Arduino e i terminali da 5 V daranno intorno ai 3,5 V. Io ho modificato un adattatore da 9 V DC esistente che avevo in una grande scatola di surplus (è incredibile quanto rapidamente queste cose possono accumularsi nel tempo). Potete trovare maggiori informazioni sugli adattatori DC Sull’Arduino Playground (http://bit.ly/apg-what-adapter).
I test finali e la chiusura Adesso che tutto si trova nella custodia, che sono state applicate le etichette e che è stato caricato il software, è il momento di sottoporre il generatore di segnale a un collaudo finale. La procedura di test in realtà è soltanto un test di regressione ed è uguale ai test che abbiamo eseguito sul prototipo. Lo scopo principale è verificare che niente sia cambiato o abbia smesso di funzionare tra il prototipo e l’unità finale. Qualsiasi ulteriore test richiederà attrezzature delle quali quasi nessuno dispone, come un analizzatore di distorsione o un analizzatore di spettro. Se per caso conoscete qualcuno che ne possiede uno o avete accesso a attrezzature di test di questo tipo, se potete utilizzatele assolutamente. A seconda di come avete in mente di utilizzare il vostro nuovo generatore di segnale, può rivelarsi utile conoscere il livello di distorsione armonica a varie frequenze (è costante, oppure cambia con la frequenza di output?) e quanto armonicamente “puro” è l’output a onde sinusoidali. Altra cose da investigare possono essere i momenti di ascensione e di caduta dell’output a onde quadre, l’impedenza dell’output, la relazione hertz-tensione dell’ingresso CV, la stabilità a lungo termine (cioè, la frequenza non si mantiene stabile dopo lunghi periodi di tempo?) e i tempi di riposta degli input dei controlli CV e gate. Una volta completati i test finali, l’ultimo passaggio è montare il coperchio. Non dimenticate di mettere alcuni paracolpi adesivi di gomma sul fondo della custodia. Non dovete ricoprirne le viti del coperchio. La Figura 11-26 mostra lo strumento finito in posa sul mio tavolo da lavoro con un oscilloscopio USB digitale e un PC portatile.
Figura 11-26 - Il generatore di segnale finito e pronto per essere messo al lavoro.
Devo segnalarvi che la maniglia dello strumento che si vede nella n Figura 11-26 presenta qualcosa di strano. Io ho mantenuto corretta l’orientazione alto-basso della custodia, ma accidentalmente ho scambiato davanti e dietro. Non voglio mentire e dire che l’ho fatto apposta, perché da parte mia è stato sicuramente un errore, ma il fatto è che in realtà funziona piuttosto bene. Normalmente, la maniglia sporge sul davanti dell’unità, quando questa è in una posizione che non richiede supporto. Con la maniglia al contrario, il generatore può sempre rimanere in una posizione inclinata, ma adesso la maniglia non occupa tanto spazio sul tavolo da lavoro. Sono stato fortunato. Gli errori non sempre danno buoni risultati come in questo caso.
Ridurre il costo Come descritto in questo capitolo, il generatore di segnale non è un progetto economico. Questo è dovuto in parte al packaging scelto, ai connettori, ai controlli e a ulteriori cose come gli estensori dei terminali a vite, la serie ausiliaria di pull-up e i moduli di protezione degli input. Se però volete ridurne il costo, esistono alcuni modi per farlo e ottenere comunque qualcosa di utile. Ho visto alcuni cloni di Arduino per soli 15 $. Il modulo DDS è una parte essenziale del progetto e quindi ecco altri 10 $. Una shield di prototipazione con terminali a vite costa circa 16 $, ma potete optare per una shield di prototipazione più semplice, semplicemente per disporre di un posto per il modulo DDS, per circa 10 $. Per ridurre ulteriormente il costo, potete dimenticarvi completamente della custodia e accontentarvi di una pila di shield su Arduino. Esistono diverse shield LCD dotate di pulsanti, come quella mostrata in “I display LCD” a pagina 264 nel Capitolo 8 e queste costano circa 12 $ ciascuna. Di solito queste shield hanno soltanto quattro o cinque pulsanti a
disposizione per funzioni programmate e quindi potete avere bisogno di riprogettare leggermente il software di interfaccia dei controlli per adattarlo a meno input dei controlli. Se non avete bisogno o interesse di disporre di un dispositivo indipendente, potete eliminare i controlli dell’LCD e i pulsanti e utilizzare l’unità sotto il controllo di un computer host soltanto con un Arduino e il modulo DDS. Si tratta di un tipo di dispositivo diverso del quale non ho parlato in questo capitolo. Se cercate qualche idea di come implementare un’interfaccia di controllo remota, potete dare un’occhiata al software presentato nel Capitolo 10 per i progetti della GreenShield e dello Switchinator. Se avete una pila di schede formata da un Arduino, una shield di prototipazione per fissare il modulo DDS e una shield LCD, l’aspetto sarà simile a quello mostrato nella Figura 11-27.
Figura 11-27 - Una versione a basso costo del generatore di segnale.
In questa configurazione, c’è un Arduino Leonardo, una shield di prototipazione con terminali a vite di Adafruit con il modulo DDS montato e una shield LCD di SainSmart con pulsanti. Sulla shield di prototipazione, è stata installata una morsettiera da 0,1 pollici (2,54 mm) per i segnali provenienti dal modulo DDS, ma non ci sono connettori, non ci sono potenziometri di controllo del livello dell’output e non ci sono contenitori. Tenete presente che senza una custodia di protezione è molto più probabile che succeda qualcosa di brutto se un cavo vagante o un cacciavite si imbatte nello stack di schede mentre è acceso e lo strumento non sarà mai robusto come sarebbe in una custodia costruita in modo solido. Una versione a basso costo del generatore di segnale DDS può farvi risparmiare circa 30 $ rispetto al prezzo della versione più elaborata descritta in questo capitolo, che significa che arriverebbe a costare circa 65 $ o meno acquistando in modo astuto. Può non valere la pena risparmiare 30 $ per creare qualcosa che non sia robusto e portatile come dovrebbe, ma, come sempre, siete liberi di scegliere.
Il costo nel dettaglio
La Tabella 11-6 elenca i componenti principali utilizzati nel generatore di segnale. Il costo totale non include cose come fili, saldature o fascette di nylon. Non include nemmeno i costi di spedizione e, in alcuni casi, alcuni rivenditori non offrono spedizioni a basso costo, ad esempio inviano un componente da 4,95 $ per 9 $ tramite UPS. In futuro, ho deciso di evitare questo tipo di rivenditori il più possibile, almeno finché non imparano come inviare i prodotti. Molti rivenditori cinesi, invece, possono impiegare un paio di settimane a recapitare le parti. Guardatevi in giro. eBay è un buon posto dove cominciare a cercare e, se non vi sentite sicuri su eBay, potete trovare offerte simili, spesso proposte dagli stessi rivenditori, anche su Amazon.com. Tabella 11-6 - L’elenco dei prezzi delle parti.
Quantità
Articolo
Fonte
Prezzo unitario
Tot. parz.
1
Custodia, Bud IP-6130
Mouser
25,40
25,40
1
Arduino Uno
Adafruit
24,95
24,95
1
Modulo DDS
DealeXtreme
7,99
7,99
1
Shield di prototipazione
Adafruit
9,95
9,95
1 set
Adattatori terminali a vite
Seeed Studio
7,50
7,50
1
Display LCD, 16 × 2
Amazon/Uxcell
4,71
4,71
3
Connettori BNC
All Electronics
1,25
3,75
2
Jack a banana
Amazon
0,67
1,34
3
Potenziometro, 10K
Amazon/Amico
1,28
3,84
1
Pulsante di accensione
All Electronics
1,35
1,35
6
Pulsanti in miniatura
All Electronics
0,60
3,60
1
Jack alimentazione DC cilindrico
Parts Express
1,98
1,98
a Il totale parziale è il costo totale di ciascuna riga di prodotti per una data quantità.
Come ho detto all’inizio di questo capitolo, il generatore di segnale descritto qui è più caro da costruire che molti dei kit esistenti. Ma di nuovo, farlo vi permette di ottenere il controllo totale del vostro dispositivo e questo genererà output a frequenze abbastanza alte da rendersi utile per radioamatori e applicazioni digitali ad alta velocità. Costo totale delle parti = 96,33 $ Nota: il costo totale non include fili, saldature, adesivi o il trasformatore da parete. I prezzi erano esatti quando è stato scritto questo libro, ma devono essere presi soltanto come riferimento perché possono aver subito qualche variazione.
Comprando in modo accorto, sospetto che si possa abbassare il costo totale a circa 75 $, anche per questa versione completa. Avere a portata di mano una vasta raccolta di parti, specialmente se le avete comprate in quantità, può anche aiutare a ridurre i costi di parti come connettori, interruttori e potenziometri. Infine, se per caso disponete di una vecchia attrezzatura di prova che non funziona più ma ha ancora la custodia in buono stato, potete essere creativi e metterci dentro il generatore di segnale.
Fonti La Tabella 11-7 elenca i distributori e i rivenditori presso i quali io ho acquistato le parti del generatore di segnale (sì, prendo nota di tutto questo, visto che si può scaricare, e anche voi dovreste prendere l’abitudine di conservare gli elenchi di tutte le ricevute e le scatole, se non lo fate già). Per ogni modulo o ogni parte ci sono numerose fonti: queste sono soltanto quelle che ho utilizzato io quando ho effettuato i miei acquisti e possono offrirvi un’idea di dove cominciare a cercare. Tabella 11-7 - Le fonti delle parti.
Distributore
URL
Adafruit
www.adafruit.com
All Electronics
www.allelectronics.com
Amazon
www.amazon.com
DealeXtreme (DX)
www.dx.com
Mouser Electronics
www.mouser.com
Parts Express
www.parts-express.com
Seeed Studio
www.seeedstudio.com
12 Progetto: un termostato intelligente
Forse avete sentito parlare dei cosiddetti termostati “intelligenti” (sospetto che molte persone ne hanno visto almeno la pubblicità). Questi dispositivi sono un tipo di controller digitale programmabile della temperatura e può essere che ne abbiate perfino uno installato a casa vostra. Alcuni permettono di cambiarne le impostazioni utilizzando Bluetooth o qualche altro metodo di connessione wireless, insieme a un’applicazione associata per smartphone o tablet. Altri offrono la possibilità di raccogliere dati e di scaricarli via wireless, cosa che può rivelarsi utile quando volete scoprire se state consumando troppa energia per riscaldare o rinfrescare casa vostra. Ne esistono anche alcuni, naturalmente, che non fanno niente più di quello che facevano i vecchi modelli con una bobina bimetallica, con l’unica differenza che utilizzano un display LCD anziché una manopola e qualche interruttore. ATTENZIONE Se scegliete di costruire e utilizzare il termostato descritto in questo capitolo, lo fate a vostro rischio e pericolo. Anche se utilizza circuiti a bassa tensione con un minimo rischio di prendere la scossa, c’è comunque il rischio che danneggi il vostro sistema di riscaldamento o raffreddamento a causa di cicli energetici eccessivi o di impostazioni della temperatura che superino i limiti di sicurezza del sistema (anche se la maggior parte di essi dispone di una protezione incorporata). Per il vostro impianto di riscaldamento o di raffreddamento, vi conviene utilizzare soltanto il circuito di controllo a bassa tensione. NON COLLEGATE IL VOSTRO TERMOSTATO PERSONALIZZATO A CIRCUITI AD ALTA TENSIONE (110 V AC o superiore). Questo include raffreddatori evaporativi e stufe elettriche.
Gli antefatti Esistono vari modi di migliorare un classico termostato a bobina bimetallica come quello mostrato nella Figura 12-1. Questo tipo di dispositivo esiste da circa un secolo e utilizza una bobina fatta di due diversi metalli, ciascuno con un coefficiente di espansione termica diverso, in modo che quando la temperatura cambia la bobina si stringe o si allenta leggermente.
Figura 12-1 - Un termostato elettromeccanico.
Questo movimento viene quindi utilizzato per unire alcuni contatti in modo da aprire o da chiudere un circuito, oppure, in alcune versioni, un piccolo tubo di vetro sigillato che contiene due contatti e una goccia di mercurio si sposta in modo che il mercurio riempia il vuoto tra i contatti e completi il circuito (il modulo sensore di inclinazione KY-017 descritto nel Capitolo 9 utilizza questa stessa tecnica). L’azione di controllo è on oppure off: nel mezzo non c’è niente. In questo capitolo, vedremo che cosa è necessario per progettare, costruire e programmare un termostato intelligente utilizzando soltanto schede Arduino già pronte per l’uso e componenti aggiuntivi facili da reperire. Ma, prima di immergerci in tutto questo, dobbiamo cercare di capire che cos’è esattamente che desideriamo misurare e controllare.
Panoramica dei sistemi HVAC L’idea principale che sta dietro l’alterazione della temperatura di una struttura è aggiungervi o togliervi calore. Oppure, per vederla in un altro modo, il freddo non è altro che l’assenza del calore e quindi possiamo alterare la quantità di calore presente in un sistema per raggiungere una determinata temperatura. Per aggiungere calore in un ambiente possiamo aggiungere una caldaia di un qualche tipo (gas naturale, propano, olio, legna o carbone), elementi elettrici oppure energia solare. In un sistema a pompa di calore, il calore dell’aria esterna viene estratto e reintrodotto nella struttura, che è simile a utilizzare un’unità A/C in senso inverso. Per togliere calore da una struttura, lo si
deve estrarre utilizzando un sistema di refrigerazione che impieghi il ciclo di condensazione ed evaporazione di un fluido refrigerante (ammoniaca, Freon o uno qualsiasi dei numerosi refrigeranti moderni). Il calore interno viene assorbito dal fluido refrigerante, che quindi lo trasferisce all’esterno in un sistema a ciclo chiuso. Alcuni sistemi di raffreddamento a grande scala utilizzano acqua refrigerata per ottenere lo stesso risultato, ma gli impianti fisici (le attrezzature e le costruzioni dove alloggiarli) tendono a essere grandi e cari da mantenere, per cui questi tipi di sistemi di solito si trovano soltanto nelle università, nei grandi uffici, negli ospedali e in altre strutture molto grandi. I sistemi con acqua refrigerata di solito non vengono utilizzati in ambienti residenziali, a meno che non si tratti di grandi condomini. In molti ambienti residenziali, il riscaldamento e il raffreddamento sono gestiti da due sistemi separati, ma in altri casi il riscaldamento e il condizionatore possono trovarsi entrambi nella stessa grande cassa situata sul tetto o sul lato della casa. Una pompa di calore è in grado sia di riscaldare che di raffreddare, a seconda di come è configurata in un dato momento, e spesso si compone di due unità, una all’interno della casa e un’altra all’esterno. In ogni caso, in un termostato convenzionale ci sarà solitamente un interruttore per selezionare il funzionamento automatico o manuale del ventilatore e un altro per selezionare la modalità (riscaldamento, raffreddamento, oppure spento). Una manopola o una leva imposta la temperatura nominale, o il setpoint. L’intero sistema, che include l’unità di riscaldamento, l’unità di raffreddamento e il termostato, può essere indicato come sistema HVAC (riscaldamento, ventilazione e condizionamento, dall’inglese heating, ventilation and air conditioning). (In realtà, il termine HVAC si incontra più spesso quando si parla di grandi sistemi commerciali, ma io lo utilizzerò qui perché è più comodo che scrivere “sistema di riscaldamento e aria condizionata”). Con la possibile eccezione di una funzione di ventilazione attiva a scambio di aria, un sistema HVAC residenziale è in grado di fare tutto quello che farebbe un sistema di grandi dimensioni, soltanto a una scala più piccola. Una cosa importante da notare è che la maggior parte dei sistemi HVAC possono funzionare e funzionano come sistemi di circolazione a ciclo chiuso. In altre parole, funzionano facendo circolare continuamente l’aria nella struttura. Anche se alcuni sistemi possono avere la possibilità di attirare aria dall’esterno oppure di scambiare l’aria tra l’interno e l’esterno (la V in HVAC), alcuni no, e di conseguenza l’odore della cena bruciata di ieri sera tenderà a fermarsi per un po’, prima di potersi finalmente dissipare. Questo è anche il motivo per il quale molte case hanno un odore diverso, unico di quella di residenza. Da bambino notavo che d’estate, quando utilizzava il condizionatore, l’interno della casa di un vicino puzzava sempre di pollo fritto e quindi pensavo che gli piacesse moltissimo. Non ho mai saputo quale fosse la vera origine di quell’odore.
Concetti fondamentali del controllo della temperatura Il controllo della temperatura implica il controllo dei sottosistemi che si occuperanno di riscaldare o di raffreddare un ambiente per raggiungere una determinata temperatura (setpoint). Nella maggior parte dei casi, si tratta di un tipo di funzionamento tutto-acceso oppure tutto-spento: nella maggior parte dei sistemi HVAC residenziali non ci sono valori
intermedi di riscaldamento o raffreddamento. Dico “nella maggior parte” perché è possibile che qualcuno, da qualche parte, disponga di un sistema di riscaldamento resistivo ad output variabile, ma io non ne ho ancora visto uno al di fuori di un laboratorio o di un impianto industriale. La natura “tutto o niente” dei sistemi HVAC fa che la temperatura interna reale non riesca mai a raggiungere esattamente il setpoint, eccetto che per brevi periodi mentre sta salendo o scendendo. Per esempio, immaginiamo che stiamo utilizzando il condizionatore, con l’obiettivo di raggiungere un setpoint di 72 °F (22 °C). Se registriamo e tracciamo sia la temperatura interna che quella esterna nel corso di una giornata, possiamo ottenere un grafico come quello mostrato nella Figura 12-2 (non si tratta di dati reali, naturalmente: ha un mero scopo illustrativo).
Figura 12-2 - Il grafico della temperatura nel corso di una giornata.
Nella Figura 12-2, possiamo vedere se il condizionatore è attivo perché la temperatura interna scende. Durante le prime ore della giornata non si accende e non si spegne spesso come più tardi. Il calore dell’esterno impiega del tempo a circolare nella struttura e migliore è l’isolamento più tempo impiega lo spazio interno a riscaldarsi. Più tardi, nel pomeriggio, il condizionatore lavora sodo per mantenere l’interno alla temperatura stabilita. Le cose non cominciano a rallentare fino alla sera tardi, quando scende la temperatura all’esterno. Un controller con soli due stati, on oppure off, viene detto regolatore a isteresi, noto anche come regolatore bang-bang. La quantità di isteresi nel regolatore determina quanto spesso il riscaldamento o il condizionatore devono accendersi e per quanto tempo. Potete immaginare l’isteresi come il ritardo tra il momento di accensione o di spegnimento di un sistema, in base a un valore preimpostato in qualche punto nel
mezzo. Un esempio fisico di questo è lo scatto di un raccoglitore ad anelli. Aprire e richiudere gli anelli richiede un piccolo sforzo, ma una volta che sono aperti o chiusi gli anelli rimangono in quello stato. La Figura 12-2 è una stima, ma rappresenta l’effetto di un termostato convenzionale sulla temperatura di una tipica struttura residenziale. Quando la temperatura interna raggiunge circa i 73 °F (22 °C), il condizionatore si accende e rimane acceso finché la temperatura non scende al di sotto dei 71 °F (21 °C). Questo significa che in questo sistema ipotetico ci sono circa 2 gradi di isteresi. Questo intervallo viene detto “banda di isteresi” (in realtà, la banda di isteresi di questo sistema è troppo ridotta e il condizionatore si accende e si spegne troppo spesso più tardi durante la giornata). Ciascuna azione on/off del sistema HVAC viene detta ciclo. La Figura 12-3 mostra che cosa succede quando la differenza tra i punti on e off diventa più piccola (meno intervallo tra Hmax e Hmin, che definisce la banda di isteresi). Il sistema riesce a mantenere meglio la temperatura del setpoint con un’isteresi più stretta, ma al prezzo di consumare un maggior numero di cicli. Idealmente, vogliamo rendere la banda di isteresi più ampia possibile, perché ogni volta che il riscaldamento o il condizionatore esegue un ciclo, si avvicina di un passo in più all’usura e al rischio di guasto e ne risente anche la bolletta elettrica.
Figura 12-3 - L’effetto dell’isteresi.
Anche se dal punto di vista energetico una banda di isteresi di 5° è più efficiente e non obera il sistema con tanti cicli come la banda di 3,5°, significa anche che la temperatura può oscillare di 7° tra caldo e freddo (ricordate che questi grafici sono illustrativi e non rappresentano dati reali). Esistono diversi fattori che influenzano quanto spesso un sistema di riscaldamento o di
raffreddamento ripeterà un ciclo e il più ovvio è quanto velocemente viene eliminato il calore quando si utilizza il condizionatore, oppure quanto velocemente viene introdotto il calore quando si utilizza il riscaldamento. Meno ovvi, ma altrettanto importanti, sono fattori come l’umidità e il flusso d’aria interno. Quando l’umidità aumenta, l’aria trattiene più calore, cosa che può aiutare quando si vuole riscaldare. Un condizionatore, inoltre, funge da deumidificatore, dal momento che condensa ed elimina l’umidità dell’aria che attraversa le bobine fredde del sistema e che l’aria secca fa evaporare il sudore più velocemente, cosa che ci permette di rinfrescarci più in fretta. L’aria stagnante (cioè, l’aria che non si muove a meno che non sia attivo il sistema HVAC) può portare a “punti caldi” o a “punti freddi” in una struttura ed è possibile che il termostato finisca per regolare soltanto una parte di uno spazio interno, se il resto dell’aria non si muove. Idealmente, un sistema di controllo della temperatura dovrebbe essere in grado di rilevare la temperatura in tutte le parti di una struttura, ma nel mondo reale questo spesso non avviene. Invariabilmente, ci sarà una stanza che riceve i raggi diretti del sole durante la giornata, mentre altre zone rimangono all’ombra, o magari una stanza dove l’aria non circola bene. Quindi, anche se il termostato sta facendo il suo lavoro per mantenere la temperatura nella zona immediatamente vicino a dove si trova al setpoint desiderato, altre parti della struttura non saranno riscaldate o rinfrescate correttamente. Semplicemente far muovere l’aria può aiutare a evitare questo e anche controllare l’umidità aiuta a determinare quando è il caso di accendere il ventilatore o di utilizzare il riscaldamento o il condizionatore. Utilizzare semplicemente un ventilatore è molto meno caro che accendere il riscaldamento o il condizionatore.
Il controllo intelligente della temperatura L’idea principale che sta dietro a un termostato intelligente è ridurre la quantità di energia che si spreca e ottenere una distribuzione della temperatura ancora più omogenea all’interno della struttura. Questo può comportare l’alterazione del tempo dei cicli (cioè, la regolazione dell’isteresi), soltanto utilizzando il sistema quando c’è qualcuno in casa, alterando il setpoint in base al momento della giornata e/o al giorno della settimana e approfittando del ventilatore integrato nel sistema HVAC. Alcune funzionalità comuni dei moderni termostati digitali commerciali sono i tempi di ciclo regolabili, la modalità di commutazione riscaldamento/raffreddamento automatica e la possibilità di programmazione giorno per giorno. Esamineremo brevemente queste capacità per vedere quali hanno senso in un piccolo progetto come quello descritto qui. I tempi di ciclo regolabili possono essere utilizzati per ridurre la frequenza dei cicli on/off di riscaldamento o raffreddamento. Questo può verificarsi quando la temperatura si trova sul setpoint o molto vicino e varia abbastanza da far accendere il riscaldamento o il condizionatore (A/C). Quello che fa, in realtà, è aumentare l’isteresi del sistema, in modo che ci metta di più a ripetere il ciclo quando la temperatura si aggira intorno al setpoint, ma la quantità di isteresi è ridotta quando la temperatura cambia rapidamente in una direzione o nell’altra durante un breve periodo di tempo. L’auto-commutazione permette al sistema di commutare tra raffreddamento e
riscaldamento come necessario. Se, per esempio, le giornate sono calde le e notti sono fredde, il termostato passa automaticamente da raffreddamento a riscaldamento durante la notte, per mantenere una temperatura interna media relativamente costante. Il termostato di Arduino supporterà l’auto-commutazione e anche i tempi di ciclo regolabili. La programmazione dei profili è un’ottima funzionalità dei termostati intelligenti. La maggior parte dei termostati digitali programmabili hanno la capacità di programmare il riscaldamento o il raffreddamento in giorni specifici della settimana, per cui se la vostra casa è vuota durante i giorni feriali è possibile ridurre alcune spese dalla bolletta elettrica non utilizzando il riscaldamento o il condizionatore quando non c’è nessuno in casa a goderselo. Per lo stesso motivo, alcuni modelli consentono di “abbassare” automaticamente il riscaldamento o il raffreddamento durante la notte, mentre i residenti della casa dormono. Il nostro controller avrà la possibilità di creare profili (a volte detti anche programmi) per il giorno, per la notte e per il fine settimana. Un termostato digitale può essere confezionato in un elegante involucro dall’aspetto high-tech e un display numerico dietro plastica smerigliata, ma queste sono soltanto caratteristiche che lo rendono più desiderabile da acquistare. Può anche essere alloggiato in una normalissima custodia di plastica. Può non sembrare così appariscente e high-tech come le unità che si trovano in commercio, ma questo non ha niente a che vedere con la qualità del suo funzionamento o con la sua facilità d’uso. Per questo progetto, è possibile risparmiare tempo e denaro utilizzando una custodia a basso costo e quello che ho deciso di utilizzare è definitivamente economico.
Gli obiettivi del progetto L’obiettivo principale di questo progetto è quello di creare un sostituto per un normale termostato residenziale. Online si trovano numerose descrizioni di progetti di termostati basati su Arduino e questo progetto è simile a molti di loro. Esistono moltissimi modi per organizzare un Arduino, un sensore di temperatura, un semplice display e un relè o due. Ciò che rende questo progetto unico è l’incorporazione di un sensore di umidità e la possibilità di utilizzare il ventilatore soltanto per far muovere l’aria e contribuire a spostare l’aria fredda o calda dove serve, senza dover accendere il riscaldamento o il condizionatore. Il nostro termostato fatto con Arduino avrà anche la possibilità di utilizzare i dati di temperatura e umidità interne per determinare se deve regolare il tempo di ciclo. Vi è anche la possibilità di aggiungere un ulteriore sensore che legga la temperatura e l’umidità esterne. Infine, utilizzeremo i relè per collegarci al controllo 24VAC esistente utilizzato dalla maggior parte dei sistemi HVAC residenziali negli Stati Uniti, e quindi non c’è nessun pericolo di prendere la scossa e nessun rischio reale per il vostro impianto di riscaldamento o di raffreddamento (almeno non dal punto di vista elettrico: è tuttavia possibile che i cicli siano troppo veloci e danneggino i componenti del compressore o la
resistenza di accensione). Questo progetto è molto semplice e richiede una quantità minima di parti e pochissime saldature. In realtà, le due sfide principali saranno trovare una buona custodia e programmare il dispositivo. Il termostato sarà progettato in modo che sostituisca un termostato residenziale a bassa tensione a quattro fili convenzionale. Non è limitato ai sistemi a quattro fili, tuttavia. Controllare soltanto una stufa o un condizionatore è semplicemente questione di non utilizzare tutte le uscite di controllo disponibili e di fare alcune piccole modifiche al software.
La definizione e la pianificazione Sulla base di quello che abbiamo visto finora, siamo in grado di identificare le caratteristiche di base che vogliamo inserire nel nostro progetto. Queste comprendono le funzioni già fornite da un termostato a quattro fili convenzionale, più alcune funzionalità aggiuntive basate sull’umidità: •
Orologio in tempo reale
•
Sensore di umidità interna
•
Sensore di temperatura interna
•
Riscaldamento o raffreddamento automatico
•
Controllo automatico del ventilatore
•
Programmazione di sette giorni
Sotto molti punti di vista, la versione base del controller HVAC è simile alle unità, disponibili nelle grandi catene di negozi per la casa (e anche in alcuni piccoli negozi di ferramenta locali), presso le case di distribuzione di sistemi HVAC e presso vari fornitori online. NOTA Questo progetto evita intenzionalmente di trattare direttamente con i circuiti di controllo ad alta tensione alternata dei sistemi HVAC. È pensato soltanto per sistemi a bassa tensione (24VAC). L’alta tensione AC può danneggiare l’attrezzatura HVAC, bruciare la vostra casa e uccidervi (non necessariamente in questo ordine). Se avete bisogno di questo tipo di sistema, vi conviene pensare di acquistare un controller commerciale con una certificazione di sicurezza UL e CSA e chiamare un elettricista o un tecnico specializzato per installarlo.
Il controller utilizzerà un Arduino Nano montato su una shield di prototipazione con terminali a vite. Per tenere traccia di data e ora, utilizzeremo un modulo RTC (real-time clock). Lo stack di PCB Arduino si monta sul coperchio della custodia. Monteremo un modulo di quattro relè all’interno della custodia, sul pannello inferiore. Tutti i collegamenti entreranno nella custodia attraverso un foro nella parte inferiore.
Il design Il termostato fatto con Arduino è destinato a sostituire un termostato standard a quattro fili. Non è adatto per sistemi con riscaldamento o raffreddamento multistadio o per sistemi a pompa di calore. È più adatto per case vecchie con un termostato convenzionale, come quello mostrato nella Figura 12-1.
Le funzionalità Il termostato fatto con Arduino ha tre funzioni fondamentali: caldo, freddo e ventilatore. La Figura 12-4 illustra un diagramma a blocchi con i componenti principali. Il segreto del successo sta nel modo in cui queste funzioni di base sono utilizzate per ottenere il funzionamento più efficiente.
Figura 12-4 - Il diagramma a blocchi del termostato fatto con Arduino.
Per varie funzioni, come l’impostazione della temperatura, l’alternarsi dei giorni della settimana e così via, utilizzeremo un encoder rotativo. La shield LCD è dotata anche di una serie di pulsanti, ma non li utilizzeremo. Molti sistemi HVAC più vecchi presentano soltanto quattro fili, mentre alcuni sistemi più recenti hanno anche cavi di alimentazione ausiliari. Se è disponibile e se nella custodia è montato anche un piccolo alimentatore, il termostato fatto con Arduino può utilizzare questa fonte AC. Per questa versione del termostato, utilizzeremo una fonte di alimentazione esterna da parete. Idealmente, sarebbe meglio condurre la corrente dai cavi dell’HVAC, ma molti vecchi sistemi non dispongono di una linea 24VAC di riserva.
La Figura 12-5 mostra come un tipico termostato più vecchio può essere collegato internamente. Gli esatti dettagli interni, naturalmente, variano da un tipo all’altro, ma l’idea di base è la stessa.
Figura 12-5 - Un tipico circuito interno di un vecchio termostato.
Una cosa fondamentale da notare in questo tipo di termostato vecchio stile è che il ventilatore è collegato in modo che sia sempre acceso quando è acceso il riscaldamento o il raffreddamento. Utilizzare il condizionatore o la stufa senza il ventilatore non è una buona idea. In alcuni sistemi, il ventilatore del riscaldamento è separato dalla quello del condizionatore e si accende soltanto quando la temperatura interna della stufa raggiunge un determinato livello.
La custodia Per la custodia ho scelto una scatola di derivazione di plastica con un coperchio rimovibile, adatto per essere montato sulla parete, come mostrato nella Figura 12-6. Dopo qualche rifinitura, la scatola verrà dipinta con un colore neutro per migliorarne l’aspetto.
Figura 12-6 - La custodia del termostato fatto con Arduino.
Sì, la custodia è davvero brutta. Non possono negarlo. Ma, in questo progetto, la preoccupazione principale era poterlo montare sulla parete e disporre di spazio interno sufficiente per i componenti. Le linguette di montaggio laterali saranno rimosse e il coperchio anteriore sarà levigato e lucidato, rifiniture che contribuiranno a migliorare il suo aspetto. I controlli sono semplici, con soltanto un display LCD e un encoder rotativo. Tutto starà comodamente sul coperchio anteriore. Il layout previsto del pannello anteriore è mostrato nella Figura 12-8.
Figura 12-7 - Lo schema del termostato fatto con Arduino.
Figura 12-8 - Il layout del pannello frontale del termostato fatto con Arduino.
Il modulo relè sarà montato sul fondo della custodia e i fili esistenti del termostato entreranno attraverso un foro nel fondo della custodia. Il modulo RTC sarà montato all’interno della custodia e il DHT22 sarà collegato alla parte inferiore in modo da rimanere esposto all’ambiente circostante. Io ho scelto di montare il DHT22 in questo modo, piuttosto che metterlo dentro, perché non avevo voglia di praticare una serie di fori nella custodia per permettere all’aria di fluire. Un’alternativa potrebbe essere quella di aprire un solo foro quadrato, abbastanza grande per il DHT22, in modo che lo si possa montare all’interno ma che abbia comunque accesso all’aria esterna. Fisseremo il termostato alla parete con quattro viti.
Lo schema Tra il prototipo e l’unità finale non ci sarà nessuna differenza significativa, per cui esiste solo una versione dello schema. Dal punto di vista elettrico, il prototipo è identico al termostato finale, ma utilizza una scheda Arduino Uno piuttosto che una Nano (la MCU AVR è la stessa su entrambi), soprattutto perché questo è quello che è montato sul prototipo. Notate che sono utilizzati tutti i pin della MCU. L’interfaccia di programmazione di Arduino, per mezzo di D0 e D1, è condivisa con l’encoder rotativo. Finché l’encoder rotativo non sarà in uso, questo non creerà conflitti. Potete inoltre notare che gli input analogici sono stati utilizzati come pin I/O digitali. Questo è del tutto normale e, se tornate al Capitolo 2 e al Capitolo 3, potete vedere come la porta dell’Atmega328 utilizzata per l’input analogico (la porta C) è anche una porta I/O standard discreta digitale. Facendo riferimento ai pin da D14 a D19, possiamo
accedervi come a qualsiasi altro pin I/O digitale. Naturalmente, gli input analogici adesso non sono disponibili, ma il termostato non utilizza nessun input analogico (a eccezione del pin A0, utilizzato dalla shield LCD) e quindi questo non è un problema. SUGGERIMENTO Il semplice fatto che la convenzione di Arduino sia quella di assegnare funzionalità come l’input analogico a determinati pin non significa che i pin non possano essere utilizzati per qualcos’altro. Questo è soltanto il modo in cui i ragazzi di Arduino.cc hanno deciso di assegnare loro un nome. Dal momento che una scheda Arduino è un breakout per la MCU, senza niente tra i pin della scheda e l’IC vero e proprio della MCU, quello che realmente determina ciò che un pin può o non può fare è la MCU, non le etichette sulla PCB.
Il software Questo è un progetto con un software molto intenso, ma la maggior parte di esso è dedicato all’interfaccia utente e al profilo attivo. La logica di controllo del funzionamento del termostato non è poi così complessa. NOTA Dovete ricordare che, dal momento che l’accento principale di questo libro è posto sull’hardware Arduino e sui relativi moduli, sensori e componenti, il software mostrato qui ha il solo scopo di mettere in evidenza i punti chiave e non di presentare esempi completi pronti per essere eseguiti. I codici completi dei software degli esempi e dei progetti si trovano su GitHub (https://www.github.com/ardnut).
A ogni iterazione, il ciclo principale del software controllerà l’input dell’utente proveniente dall’encoder rotativo, aggiornerà i dati di temperatura e umidità correnti e determinerà se il display deve passare a un’altra schermata, ad altre impostazioni o modificare i valori. Per catturare gli input dell’encoder rotativo, vengono utilizzati gestori degli interrupt. Nella Figura 12-9 è mostrata una versione di alto livello del diagramma a blocchi del software.
Figura 12-9 - Il diagramma a blocchi del software del termostato fatto con Arduino.
I principali blocchi funzionali nella Figura 12-9 danno un’indicazione di che cosa aspettarsi in termini di codice sorgente. Oltre al file principale Thermostat.ino, ci saranno moduli sorgente per gestire gli input dell’utente utilizzando interrupt, per programmare gli orari (diurno, serale o fine settimana) e per aggiornare il display. La prima cosa che controlla il ciclo è l’interruttore (SW, switch) sull’encoder rotativo. Questo è il segnale che indica che l’utente vuole fare qualcosa. L’interruttore a pulsante dell’encoder rotativo viene utilizzato per spostarsi tra le schermate e tra i campi di una schermata. Il tipo di azione è determinato da quanto tempo è tenuto premuto l’interruttore. I gestori degli interrupt per l’interruttore dell’encoder rotativo e gli input A/B impostano flag nel modulo delle variabili globali. Il ciclo principale li esamina per determinare quale azione di aggiornamento del display eseguire, se necessario. I gestori degli interrupt
non vengono mostrati nella Figura 12-9. Li vedremo in “Il software” a pagina 496. Il blocco con l’etichetta “Heat/cool/fan control” è la logica di controllo vera e propria del termostato. Come ho detto in precedenza, questo è un regolatore di isteresi a stati discreti, noto anche come regolatore “bang-bang”. La Figura 12-10 mostra la relazione tra la temperatura, il tempo e l’intervallo di isteresi in un formato temporale per un sistema A/C. Per il riscaldamento, il funzionamento è semplicemente l’inverso.
Figura 12-10 - Tempo, temperatura e intervallo di isteresi.
Nella Figura 12-11 è mostrato un altro modo di rappresentare questo. Questo grafico mostra l’isteresi come una funzione della temperatura. Il messaggio di entrambi i tipi di grafici è lo stesso: un sistema di controllo bang-bang (come un termostato) associato a un attuatore on/off (la stufa o il condizionatore) non possono mai mantenere con precisione una specifica temperatura. Il sistema si troverà sempre in un qualche punto tra le estremità superiori e inferiori dell’intervallo di isteresi.
Figura 12-11 - L’effetto dell’isteresi sulla risposta del sistema di controllo.
In un sistema reale, la velocità alla quale la temperatura aumenta o diminuisce dipenderà dalla velocità con cui il calore viene introdotto o estratto dal sistema e dall’efficienza con la quale il riscaldamento o il raffreddamento possono aggiungere o eliminare calore. Il risultato è che i tempi di riscaldamento e di raffreddamento non saranno quasi mai gli stessi, anche se sia dalla Figura 12-10 che dalla Figura 12-11 potrebbe sembrare che lo siano. La logica di controllo del termostato è mostrata nella Figura 12-12. Notate che il riscaldamento e il raffreddamento sono semplicemente operazioni inverse. In un termostato elettromeccanico vecchio stile, il termine H (isteresi) viene stabilito utilizzando una vite di fissaggio sul gruppo della bobina bimetallica. Nel software, se vogliamo possiamo impostarlo dinamicamente.
Figura 12-12 - La logica di controllo del termostato per riscaldamento e raffreddamento.
Gli input/output dell’utente L’input dei controlli è costituito da un unico encoder rotativo. Questo può sembrare strano, ma un encoder ha integrato anche un interruttore che si attiva quando l’utente preme la manopola. L’interruttore viene utilizzato per passare tra le varie configurazioni sul display (o schermate, come le chiamo io). Ciascuna schermata contiene campi che mostrano dati o impostazioni e l’encoder rotativo viene utilizzato anche per spostarsi tra i campi di ciascuna schermata. La durata della pressione del pulsante dell’encoder rotativo determina quale azione deve eseguire il software. Una pressione breve rappresenta una selezione, mentre una pressione lunga chiede al software di passare alla schermata successiva. Il display è lo stesso tipo di LCD 16 × 2 che abbiamo utilizzato con il generatore di segnale nel Capitolo 11. In questo progetto, è già montato su una shield. Questo semplifica i collegamenti interni. La retroilluminazione dell’LCD non è attivata, a meno che non siano attivi gli input dei controlli. I piccoli interruttori a pulsante della shield LCD non vengono utilizzati, ma potrebbero esserlo, se volete aprire ulteriori fori sul pannello anteriore e trovare delle estensioni di qualche tipo che un utente possa premere. Io ho scelto di ignorarli. Normalmente, appaiono due schermate principali che si alternano quando non sono attivi gli input dei controlli. La prima mostra la temperatura corrente, il setpoint, la modalità operativa e il profilo attivo (se ce n’è uno). La seconda schermata mostra la data e l’ora correnti. La Figura 12-13 mostra le schermate durante il funzionamento normale. I
simboli ^, v e – servono rispettivamente a indicare se un risultato sta salendo, scendendo o se sta rimanendo stabile, in relazione a quello precedente. I campi mostrati nella Figura 12-13 sono definiti nella Tabella 12-1. Nella seconda schermata, il campo “END” mostra l’ora nella quale sarà terminato il profilo corrente.
Figura 12-13 - Le schermate del funzionamento normale.
Tabella 12-1 - Le definizioni dei campi della schermata normale.
Campo
Scopo
T
Temperatura interna corrente, in gradi (F o C)
E
Temperatura esterna (se attivata)
H
Umidità
M
Modalità: A (automatica), H (caldo), C (freddo), F (ventilatore) o X (spento)
P
Profilo: D (giorno), N (notte), W (weekend) o X (nessuna)
Le schermate mostrate nella Figura 12-13 sono puramente informative e non presentano campi modificabili. La temperatura può essere espressa in gradi Celsius oppure in gradi Fahrenheit. L’impostazione predefinita è Fahrenheit. Per l’ora, io ho scelto di utilizzare il formato a 24 ore, ma può essere modificato per utilizzare il formato a 12 ore (AM/PM) senza troppa fatica. La schermata delle impostazioni, mostrata nella Figura 12-14, permette all’utente di attivare o di visualizzare il profilo e, se il profilo è disattivato, l’utente può regolare manualmente il setpoint della temperatura, la scala della temperatura, l’isteresi e la modalità operativa.
Figura 12-14 - La schermata delle impostazioni.
La schermata delle impostazioni è il punto di controllo principale del termostato. È organizzata intenzionalmente in modo che appaia soltanto quando viene invocata esplicitamente da un utente. I campi utilizzati nella schermata delle impostazioni sono elencati nella Tabella 12-2. Tabella 12-2 - Le definizioni dei campi della schermata delle impostazioni.
Campo
Scopo
S
Setpoint della temperatura
C
Intervallo del ciclo (isteresi, in gradi)
F
F o C per la scala della temperatura
O
Tempo di override
M
Modalità: A (automatica), H (caldo), C (freddo), F (ventilatore) o X (spento)
P
Profilo: D (giorno), N (notte), W (weekend) o X (nessuno)
La forma principale di controllo predeterminato per il termostato sono i profili definiti dall’utente. I profili si definiscono nella schermata mostrata nella Figura 12-15.
Figura 12-15 - La schermata di modifica dei profili.
Ci sono profili per il giorno, per la notte e per i fine settimana, che sono etichettati rispettivamente D, N e W. Ruotando l’encoder quando è selezionata la schermata di modifica dei profili, si selezionano in sequenza i tre profili. Ciascun profilo ha un’ora di inizio e un’ora di fine. Nel caso del profilo del weekend (W), l’ora di inizio predefinita è venerdì a mezzanotte e l’ora di fine è la mezzanotte di domenica. Se l’ora di fine di un
profilo si sovrappone all’ora di inizio di un altro, l’ora di fine del profilo precedente prende sempre la precedenza. I campi utilizzati nella schermata di modifica dei profili sono elencati nella Tabella 12-3. Tabella 12-3 - Le definizioni dei campi della schermata di modifica dei profili.
Campo
Scopo
P
Profilo: D, N, W
B
Ora di inizio
E
Ora di fine
S
Setpoint della temperatura
C
Intervallo del ciclo (isteresi)
M
Modalità: A (automatica), H (caldo), C (freddo), F (ventilatore) o X (spento)
Per navigare tra le schermate e i campi è necessario abituarsi un po’, ma, utilizzando la durata della pressione del pulsante dell’encoder rotativo e una struttura ad albero, un utente più navigare nelle schermate e nei campi principali senza perdersi. La Figura 1216 mostra come rispondono le schermate e i campi a pressioni lunghe o corte. La Figura 12-17 mostra tutte e quattro le schermate in un’unica vista. Questa dovrebbe aiutare a visualizzare con maggiore facilità come sono organizzate le schermate. Una pressione lunga del pulsante è definita come di 1 secondo o più. Una pressione breve del pulsante è di 500 ms o meno. Per controllare la durata della pressione del pulsante, il software utilizza un interrupt e un contatore.
Figura 12-16 - La schermata del termostato e la navigazione dei campi.
Figura 12-17 - Le quattro schermate utilizzate dal termostato.
L’output dei controlli L’output dei controlli consiste di un modulo con quattro relè SPDT indipendenti. Incorpora i driver dei relè e le morsettiere della PCB, per cui collegarlo ai fili esistenti del termostato è semplice, come si può vedere nella Figura 12-18. La linea comune passa per il quarto (in basso a sinistra nel diagramma) relè.
Figura 12-18 - Il prototipo del termostato fatto con Arduino.
Nel diagramma a blocchi della Figura 12-4, noterete che la linea comune proveniente dal sistema HVAC esistente passa anche per uno dei relè. Questa è una misura di sicurezza. Se il termostato perde l’alimentazione, il relè con la linea comune cade e nessuna delle altre funzioni dell’HVAC può essere attivata. Tutte le linee di tensione di controllo esterne dell’HVAC, compreso il ritorno comune, sono collegate ai terminali C e NO (comune e normalmente aperto) dei relè.
Il prototipo Il prototipo per questo progetto è formato da un Arduino Uno, una coppia di estensione delle morsettiere e una shield LCD. Questi sono essenzialmente gli stessi componenti che confezioneremo nella custodia più tardi (la scheda Nano e la scheda Uno utilizzano la stessa MCU ATmega328). Sto riutilizzando l’Arduino integrato che abbiamo utilizzato nel Capitolo 11 per il generatore di segnale, ma potrei anche aver utilizzato il Duinokit introdotto nel Capitolo 10. Io ho scelto di assegnare alla scheda un’altra missione perché è sufficientemente piccola da poter essere montata sulla parete accanto al termostato esistente durante i test. Il prototipo è mostrato nella Figura 12-18. Il prototipo utilizza una serie di parti leggermente diversa, ma equivalente dal punto di
vista elettrico, rispetto all’unità finale. La shield LCD è la stessa che utilizzerà l’unità finale, ma la scheda Arduino è una Uno laddove l’unità finale utilizzerà una Nano. Nella Figura 12-18 potete vedere l’encoder rotativo, il modulo RTC e il sensore DHT22 sulla piccola breadboard che non richiede saldature. L’elenco delle parti del prototipo è fornito nella Tabella 12-4. Tabella 12-4 - L’elenco delle parti del prototipo del termostato.
Quantità
Descrizione
1
Arduino Uno (o equivalente)
1
Shield display LCD 16 × 2
1
Modulo real-time clock DS1302
1
Serie di adattatori per i terminali a vite
1
Modulo con quattro relè
1
Sensore di temperatura/umidità DHT22
1
Modulo encoder rotativo KEYES KY-040
Il sensore DHT22 Per rilevare la temperatura e l’umidità, utilizzeremo il dispositivo DHT22, che è lo stesso dispositivo che abbiamo utilizzato con la GreenShield nel Capitolo 10. Nella versione finale, collegheremo il sensore DHT22 a un Arduino Nano, con terminali a vite. Il pinout del DHT22 è mostrato nella Figura 12-19.
Figura 12-19 - Il pinout del sensore DHT22.
Sulla linea dei dati, utilizzeremo una pull-up da 1 kohm, come consiglia la scheda tecnica (che si trova presso Adafruit (http://www.adafruit.com/), SparkFun (http://www.sparkfun.com/) e altri). Nel prototipo, il DHT22 sarà collegato utilizzando una piccola breadboard che non richiede saldature su una base di legno, come si può vedere nella Figura 12-18.
L’encoder rotativo Il principale (e unico) input di controllo è un modulo KEYES KY-040 (nel Capitolo 9 trovate maggiori informazioni sui moduli KEYES) con un encoder rotativo Bonatech, simile a un Alps EC11. Il modulo è mostrato nella Figura 12-20 e il pinout è mostrato nella Figura 12-21.
Figura 12-20 - Il modulo encoder rotativo.
Figura 12-21 - Le funzioni dei pin del modulo encoder rotativo.
Il circuito del modulo encoder rotativo è semplice, come mostra la Figura 12-22. L’encoder contiene un interruttore interno che si attiva quando si preme l’albero e le tre linee del segnale utilizzano resistenze pull-up da 10K. I pin etichettati CLK e DT
corrispondono ai segnali A e B (rispettivamente) che si trovano nella maggior parte degli esempi software e delle descrizioni di encoder rotativi semplici.
Figura 12-22 - Lo schema del modulo encoder rotativo.
L’interruttore integrato nell’encoder rotativo si utilizza per passare da una schermata all’altra del display e anche per vari elementi delle schermate che possono essere modificati dall’utente. Questo e l’encoder rotativo vero e proprio sono gli unici due input di controllo. L’interruttore interno è normalmente aperto.
Il modulo real-time clock Per poter determinare quale profilo utilizzare, il termostato deve poter tenere traccia del tempo. Per questo scopo, utilizziamo un modulo RTC (real-time clock) basato su un IC DS1302. Il modulo RTC in realtà non è niente più che un carrier per l’IC DS1302, un cristallo e una batteria. La Figura 12-23 mostra uno schema del modulo RTC. Il pinout è molto intuitivo.
Figura 12-23 - Lo schema del modulo RTC.
Sull’Arduino Playground (http://bit.ly/apg-ds1302rtc) è disponibile una libreria per il DS1302. Il termostato utilizzerà questa, anziché creare una nuova libreria a partire da zero.
La shield LCD La shield LCD, che potete vedere nella Figura 12-18 e che è descritta nel Capitolo 8, è una shield comune che si trova facilmente. Si tratta della parte che utilizza più pin I/O digitali della scheda Nano. In questa applicazione, la shield è stata scelta perché incorpora un potenziometro per il contrasto e un transistor per controllare la retroilluminazione del display. Inoltre, si collega direttamente all’Arduino sottostante, eliminando collegamenti come quelli che abbiamo utilizzato nel generatore di segnale nel Capitolo 11.
Il software Il software del termostato è semplice e, come la maggior parte dei software integrati, è progettato per girare continuamente con un ciclo principale. A differenza di altri esempi presentati fino a questo punto, per gestire l’encoder rotativo il termostato utilizza interrupt. Implementare un gestore di interrupt con un Arduino non è particolarmente difficile e per adesso gli interrupt sono il modo migliore di gestire gli eventi asincroni del mondo reale.
L’organizzazione del codice sorgente Come nel caso di altri progetti di questo libro, il codice sorgente è organizzato come una serie di file sorgente (vedere Tabella 12-5). Questi includono il modulo principale con le funzioni setup() e loop(), un modulo per le variabili globali e la logica per controllare le funzioni dell’HVAC in accordo con “programmi” di riscaldamento e/o raffreddamento definiti dall’utente. Il modulo display prende in prestito del lavoro già eseguito per il generatore di segnale nel Capitolo 11 e il modulo dell’interfaccia, tstat_iface.cpp, include anche il gestore di interrupt per l’encoder rotativo. Tabella 12-5 - I moduli di codice sorgente del termostato.
Modulo
Funzione
Thermostat.ino
Modulo principale che contiene setup() e loop()
tstat.h
Definizioni delle costanti (dichiarazioni #define)
tstat_ctrl.cpp
Logica di controllo dell’HVAC
tstat_ctrl.h
File include
tstat_gv.cpp
Variabili globali
tstat_gv.h
File include
tstat_iface.cpp
Elaborazione degli input di controllo
tstat_iface.h
File include
tstat_lcd.cpp
Funzioni LCD
tstat_lcd.h
File include
tstat_util.cpp
Funzioni utility
tstat_util.h
File include
La descrizione del software Il software può essere suddiviso in tre sezioni funzionali: interfaccia utente, logica di controllo e gestione del display. Le funzioni dell’interfaccia utente, contenute nel modulo sorgente tstat_iface.cpp, forniscono la funzionalità di lettura dell’encoder rotativo e di navigazione nelle schermate del display. tstat_lcd.cpp contiene le funzioni per gestire il display LCD. Il modulo sorgente tstat_ctrl.cpp fornisce la funzionalità per rilevare temperatura e umidità per mezzo del sensore DHT22, la logica del controller e i programmi definiti dall’utente. In questo progetto si utilizzano varie librerie per l’RTC DS1302, l’encoder rotativo, le funzioni di data e ora e la periferica timer 1 dell’AVR. Queste sono elencate nella Tabella 12-6. Questo è uno degli aspetti positivi di lavorare con Arduino: se avete bisogno di una libreria per utilizzare un determinato modulo, sensore o shield, molto probabilmente qualcuno, da qualche parte, si è preso il tempo di crearla e quindi non dovrete farlo voi. Tabella 12-6 - Le librerie esterne utilizzate con il termostato.
Nome
Funzione
Autore
Time
Funzioni relative al tempo
Michael Margolis
DS1302RTC
Classe RTC
Timur Maksimov
ClickEncoder
Classe encoder rotativo
Peter Dannegger
TimerOne
Classe timer 1
Lex Talionis
Queste librerie si trovano sull’Arduino Playground (http://playground.arduino.cc/) e su GitHub (http://www.github.com/). Vi conviene leggere la documentazione inclusa e il codice sorgente, per riuscire a capire meglio che cosa fa il codice e come configurarlo se necessario. La libreria DHT22 è la stessa che abbiamo usato con la GreenShield nel Capitolo 10. Il file tstat.h contiene le definizioni globali utilizzate da altri moduli. Questi seguono le assegnazioni dei pin mostrare nella Figura 12-7, illustrate nell’Esempio 12-1. Esempio 12-1 - Le definizioni I/O di tstat.h.
La funzione setup() che si trova in Thermostat.ino, mostrata nell’Esempio 12-2, inizializza l’LCD, fa apparire alcuni messaggi di avvio, controlla il modulo RTC e mostra la prima schermata. Esempio 12-2 - La funzione setup().
La funzione loop() che si trova in Thermostat.ino non è complicata, come potete vedere nell’Esempio 12-3. La maggior parte del lavoro ha luogo quando è in uso l’encoder rotativo e quando il software sta ricavando i dati relativi a temperatura e umidità ed eseguendo le funzioni di controllo contenute in tstat_ctrl.cpp. Esempio 12-3 - La funzione loop() principale del termostato.
Quando l’encoder non è in uso, il display alternate tra le schermate 1 e 2, che mostrano rispettivamente le condizioni attuali e lo stato operativo e data e ora. Quando l’encoder viene utilizzato, il flag input_active viene impostato su true e rimane true finché l’utente non ritorna nella schermata 1 premendo la manopola dell’encoder per attivarne l’interruttore. Notate che il controllo del sistema è ancora attivo mentre le schermate degli input sono in uso.
I test
I test sono un procedimento di tre passaggi e questo paragrafo vale sia per il prototipo che per l’unità finale. Il primo passaggio implica l’impostazione della data e dell’ora nell’RTC. Per farlo, basta passare alla schermata di configurazione di data e ora utilizzando il pulsante dell’encoder. Dopo essere tornati nel display principale, si devono vedere l’ora e la data corrette. Il passaggio successivo consiste nell’impostazione della temperatura desiderata, l’intervallo di isteresi (il parametro C sul display) e la modalità operativa. Io ho cominciato verificando che possa attivare manualmente il ventilatore del sistema e poi ho inserito il setpoint della temperatura e ho impostato la modalità. Vi conviene guardare il display e verificare che il sistema interrompa il riscaldamento o il raffreddamento quando raggiunge una temperatura uguale al setpoint più o meno metà dell’intervallo del ciclo (isteresi). Infine, possiamo passare in rassegna i vari profili e impostarne ciascuno nel modo che consideriamo più adatto per la nostra situazione. Ricordate che un conflitto tra l’ora di fine di un profilo e quella d’inizio di un altro si risolve rispettando l’ora di fine del profilo precedente e non quella d’inizio del successivo. Vi conviene tenere d’occhio il funzionamento del termostato per un periodo di circa un paio di settimane. Probabilmente richiederà qualche perfezionamento, per stabilire le ore e i setpoint ideali per ottenere il funzionamento più efficiente. Se avete costruito una GreenShield, potete utilizzarla per registrare la temperatura e l’umidità e catturare i dati delle prestazioni del termostato. Per interrogare la GreenShield a intervalli regolari e raccogliere dati, un semplice script Python andrà benissimo.
La versione finale La versione finale del termostato è diversa da quella del prototipo sotto alcuni aspetti fisici, ma altrimenti è identica in termini di funzioni e collegamenti del segnale. Le tre differenze principali sono l’utilizzo della scheda Nano, un semplice modulo LCD anziché una shield LCD e una custodia dove montare il tutto. L’elenco delle parti della versione finale del termostato è fornito nella Tabella 12-7. Tabella 12-7 - L’elenco delle parti della versione finale del termostato.
Quantità
Descrizione
1
Arduino Nano (o equivalente)
1
Scheda di prototipazione con terminali a vite
1
Modulo display LCD 16 × 2
1
Modulo con quattro relè
1
Sensore di temperatura/umidità DHT22
1
Modulo encoder rotativo KEYES KY-040
1
Modulo real-time clock
1
Custodia di plastica
L’assemblaggio L’assemblaggio finale consiste principalmente in montare i componenti e inserire il tutto nella custodia. Ma, prima, io ho apportato alcune modifiche alla custodia. Ho grattato via le lettere dal coperchio superiore, ho rimosso le linguette di montaggio dai lati e ho aperto dei fori per il display e per l’encoder rotativo. Ho aperto dei fori anche sul fondo della custodia, per montare le viti e la stufa esistente e i fili per controllare il condizionatore. Poi, dopo aver fatto tutto questo, ho dipinto la custodia di un colore neutro in sfumatura d’avorio. Ho utilizzato una shield di prototipazione con terminali a vite per fissare la scheda Nano e ho collegato i pin della Nano ai terminali e ai corretti pin header. La Figura 12-24 mostra la vista dall’alto della shield di prototipazione della Nano, con la shield LCD, l’encoder rotativo e il modulo RTC. Il modulo RTC sarà montato all’interno della custodia.
Figura 12-24 - La scheda di prototipazione della Nano e altri componenti.
Dal momento che ho scelto di tenere tutti i collegamenti sul lato superiore della shield di prototipazione, il lato inferiore della shield non presenta altro che piazzole di saldatura.
Ho utilizzato il filo isolato a trefolo più sottile che avevo a mia disposizione (28 AWG a 7 trefoli) senza dover ricorrere a filo per wire-wrap. Il filo solido da 30 AWG con isolamento Kynar è ideale per la costruzione wire-wrap, ma è meno adatto nel nostro caso. Il grande vantaggio offerto dalla shield di prototipazione con terminali a vite è la facilità con i quali i fili da e altri componenti possono essere collegati ai terminali. Nel caso del termostato, questo include il sensore DHT22, il modulo real-time clock, il modulo relè e l’encoder rotativo. La Figura 12-25 mostra come si presentava la custodia dopo le modifiche. La shield LCD shield e l’encoder rotativo sono già montati. Quello che non si vede è il sensore DHT22, che è montato sulla parte esterna del fondo della custodia. Potete notare anche che le viti del coperchio non sono installate.
Figura 12-25 - La custodia del termostato quasi finita.
Il piccolo foro in alto a sinistra nella finestra dell’LCD è un foro di accesso per il potenziometro della shield LCD che serve a regolare il contrasto del display. Come ultimissimo passaggio, procederemo a ritagliare un po’ il bordo della finestra dell’LCD e anche un coperchio di plastica trasparente può essere una buona idea. Sì, sembra scappato da un ambiente industriale, ma, come ho detto prima, il modo in cui si presenta non ha conseguenza sul modo in cui funziona. La manopola dorata c’è (se potete vedere l’immagine a colori) perché era l’unica manopola che avevo a
disposizione. Il modulo con quattro relè si monta sul fondo della custodia. Il modulo RTC si monta su un lato interiore della scatola. La Figura 11-25 mostra come sono organizzate le cose nella custodia. I collegamenti esistenti dell’HVAC sono collegati per mezzo di un foro di accesso sul fondo della custodia. Notate che il foro è spostato verticalmente rispetto al centro, per lasciare spazio al modulo relè. Tutto è un po’ giusto, a dire il vero, ma ci sta. Sono necessari ancora diversi passaggi prima di chiudere e rilassarsi: 1. Trovare le posizioni delle viti di montaggio sulla parete e fare i buchi. 2. Estrarre i fili di controllo esistenti dell’HVAC attraverso il foro sul fondo e montare la custodia sulla parete. 3. Collegare i fili dell’HVAC al modulo relè. 4. Collegare l’alimentazione e controllare il display. 5. Mettere il coperchio alla custodia. Dando per scontato che il software sia già caricato sulla scheda Nano, il termostato adesso deve funzionare. Non ha un interruttore di accensione e quindi comincia a funzionare non appena si collega l’alimentatore. La retroilluminazione del display deve rimanere attiva per 15 secondi dopo che si è fornita l’alimentazione e quindi potete dover girare leggermente la manopola dell’encoder se ha fatto timeout e si è spenta.
Figura 12-26 - I componenti interni del termostato.
La custodia è dotata di una guarnizione in gomma, che potete utilizzare se pensate che sia necessario. Io l’ho utilizzata semplicemente perché consente una perfetta aderenza del coperchio e offre un po’ più di spazio all’interno per i componenti, ma non mi preoccupa il fatto che la pioggia possa entrare nell’unità.
I test e il funzionamento Per eseguire i test, dobbiamo utilizzare l’encoder per vedere tutte le schermate del display e verificare che il rilevamento dell’interruttore lungo e corto funzioni correttamente. Dovremo impostare di nuovo i parametri, dal momento che caricare il software non carica la EEPROM, ma soltanto la memoria flash dei programmi. Se l’unità installata sembra funzionare correttamente, potete cominciare a configurarla per il vostro particolare ambiente e in base alle vostre preferenze. Vi suggerisco di cominciare con qualcosa di semplice, come per esempio limitarvi a controllare il riscaldamento e il raffreddamento. Dopo che sarete soddisfatti del fatto che l’unità sta funzionando come dovrebbe, potete decidere di impostare i profili giorno/notte e vedere come funzionano. Man mano che acquisite una maggiore esperienza con l’unità, potete incorporarvi le impostazioni di umidità e tempo del ciclo. Perché funzioni nel modo ideale, un dispositivo come questo richiede una certa quantità di “regolazioni” e quindi si integrerà in modo efficace nel vostro ambiente.
Il secondo DHT22 Potete ricordare dalla Figura 12-4 che c’è un input per un secondo sensore DHT22. Io ho scelto di lasciarlo stare per la prima iterazione di questa unità, in modo da potermi concentrare sulle funzionalità essenziali. Dal punto di vista elettrico, incorporare l’input di un secondo DHT22 è semplice, ma introduce un nuovo livello di complessità nel software. Il motivo è che con una secondo sensore il termostato deve non soltanto monitorare l’ambiente interno, ma adesso deve anche tener conto di quello esterno (cose come la differenza tra la temperatura interna e quella esterna, la velocità di cambiamento in ogni determinato momento e la perdita o l’aumento di calore stimato per via di pareti e finestre). Con un po’ di fatica e una buona programmazione, il termostato può cercare di equilibrare i vari fattori e arrivare al profilo di riscaldamento e raffreddamento ottimale. Può suonare molto interessante, ma non è facile. Come nel caso di tutti i software mostrati in questo libro, il codice sorgente del termostato è disponibile su GitHub (https://www.github.com/ardnut). Occasionalmente, pubblicherò aggiornamenti del termostato e degli altri progetti di esempio.
Il costo nel dettaglio Uno degli obiettivi di questo progetto era utilizzare il più possibile schede e moduli già pronti. Questo non soltanto permette di risparmiare tempo e fatica, ma aiuta anche a mantenere bassi i costi (le PCB personalizzate non sono economiche). Dal punto di vista della costruzione, questo progetto ha richiesto molta meno fatica rispetto al generatore di segnale del Capitolo 11. La Tabella 12-8 elenca i componenti principali. Tabella 12-8 - L’elenco dei prezzi dei componenti del termostato.
Quantità
Articolo
1
Arduino Nano
1
Shield di prototipazione con terminali a vite
1
Modulo RTC
1
Modulo encoder rotativo
1
Shield display LCD
2
Sensori DHT22
1
Modulo con quattro relè
1
Custodia elettrica
Fonte
Prezzo unitario
Tot. parz.
SainSmart
14,00 $
14,00 $
Adafruit
15,00 $
15,00 $
DealeXtreme
2,00 $
2,00 $
Various
6,00 $
6,00 $
SainSmart
10,00 $
10,00 $
Adafruit
10,00 $
20,00 $
SainSmart
7,00 $
7,00 $
Home Depot
7,00 $
7,00 $
a Il totale parziale è il costo totale di ciascun articolo per una data quantità.
Costo totale delle parti = 81,00 $
Notate che i moduli KEYES, come l’encoder rotativo KY-040, spesso si trovano in kit di moduli. Possono essere acquistati come articoli singoli presso rivenditori su eBay e Amazon, ma scegliere uno dei kit risulta più economico. Come nel caso degli altri progetti di esempio presentati in questo libro, probabilmente potete trovare prezzi migliori di quelli mostrati nella Tabella 12-8 cercando in giro e trovando offerte speciali. Ho visto schede tipo Nano vendute per soli 5 $ e sensori DHT22 con prezzi tra i 7 $ e gli 8 $.
Prossimi passaggi Questo progetto è un esempio dei limiti che potete incontrare quando create dispositivi complessi utilizzando soltanto shield e moduli già pronti. Se dovessi creare la Versione 2 del termostato, costruirei una PCB personalizzata che contenga tutto su una sola scheda. Come la GreenShield del Capitolo 10, sarebbe dotata di relè integrati e vi includerei anche un alimentatore. Questo design è anche un ottimo candidato per un multiplexer I/O come il MPC23017 che abbiamo utilizzato nella PCB dello Switchinator nel Capitolo 10. Il display LCD può essere controllato con un MPC23017. Adafruit vende una versione della shield display con un MPC23S17, che è la versione SPI dell’IC. Inoltre, utilizzerei parti a montaggio superficiale per tutto eccetto forse per i relè, il DHT22 e le morsettiere. Penso che la dimensione dei relè possa essere leggermente ridotta, magari anche con parti a montaggio superficiale, dal momento che in realtà non devono gestire molta corrente sui contatti. Con un design attento e parti ben selezionate, la dimensione dell’intera PCB può essere ridotta in modo significativo. Alcune funzionalità desiderabili che semplicemente non ci stanno sul design attuale sono un’interfaccia Bluetooth o WiFi, un lettore di schede flash microSD per registrare dati a lungo termine e magari qualche ulteriore LED per il pannello anteriore. Così com’è, il termostato fatto con Arduino è quasi un dispositivo IoT (Internet of Things), ma per diventarlo del tutto richiede qualche modifica e qualche miglioramento. Di tutte le cose pubblicizzate come dispositivi IoT, un termostato può avere molto senso. Non sono convinto che lasciare che la caffettiera o il forno a microonde parlino con il frigorifero sia una buona idea.
Fonti La Tabella 12-9 elenca i distributori e i rivenditori presso i quali io ho acquistato i componenti del termostato. Come nel caso di tutti i progetti di esempio presentati in questo libro, la maggior parte dei componenti si trovano presso varie fonti. Queste sono semplicemente quelle che ho utilizzato quando ho effettuato i miei acquisti.
Tabella 12-9 - Le fonti delle parti.
Distributore
URL
Adafruit
www.adafruit.com
DealeXtreme (DX)
www.dx.com
DFRobot
www.dfrobot.com
SainSmart
www.sainsmart.com
Ho trovato la custodia nel settore di elettricità del negozio Home Depot della mia zona, ma potete trovare custodie elettriche simili presso qualsiasi ferramenta ben fornita.
13 Il modellino di lanciarazzi: lo studio di un design
Questo capitolo è diverso dai tre capitoli precedenti. Invece di utilizzare un progetto di esempio (o diversi progetti, nel caso del Capitolo 10) per illustrare come si applicano in applicazioni reali i concetti, gli strumenti e i componenti descritti nei capitoli precedenti, questo capitolo illustra come eseguire lo studio di un design. Non costruiremo niente di concreto, ma definiremo alcuni approcci possibili, identificheremo gli strumenti e i componenti più adatti e valuteremo i compromessi di design. Questo tipo di attività di ingegneria può essere applicato non soltanto ai modellini di lanciarazzi, ma a qualsiasi progetto di design con Arduino che presenti un grado qualunque di complessità. NOTA Ricordate che, dal momento che in questo libro l’enfasi principale è posta sull’hardware e sui relativi moduli, sensori e componenti di Arduino, il software mostrato qui serve esclusivamente a sottolineare i punti chiave e non a presentare esempi pronti per l’uso. Il codice completo del software relativo a esempi e progetti si trova su GitHub (https://www.github.com/ardnut).
Panoramica Un lanciarazzi controllato da Arduino è un’applicazione interessante per diverse ragioni. Innanzitutto, è molto estensibile e lo si può portare fino al punto che si vuole (e si può), entro i limiti imposti dall’hardware di Arduino. In secondo luogo, dal punto di vista fisico il lanciarazzi può essere qualsiasi cosa: da una piccola scatola di plastica con un interruttore e un LED a una console con cifre digitali e uno o due interruttori. Terzo, il lanciarazzi può supportare una vasta gamma di funzioni, al di là semplicemente della possibilità di applicare corrente a un accenditore. Può essere collegato per mezzo di WiFi o di Bluetooth, avere la possibilità di controllare l’accenditore continuamente, generare una voce sintetica che annunci il conto alla rovescia e lo stato del lancio, input di sicurezza e perfino la capacità di scollegare l’alimentazione da un razzo prima del lancio per mantenere le batterie completamente cariche. Quanta (o quanta poca) fatica volete fare dipende dai vostri obiettivi, dalle vostre capacità e dalla vostra disponibilità economica. Prima di arrivare alla fine di questo capitolo, dovete essere diventati capaci di prendere
decisioni coscienti su quale hardware acquistare, su quanto deve essere difficile il software da scrivere e su come anticipare il livello di impegno che richiederà un determinato design. Utilizzando il materiale presentato nei capitoli precedenti, dovete riuscire a creare un elenco di componenti e a farvi un’idea di quanto costerà il design e di quanto sarà difficile da costruire. Dovete essere anche in grado di creare un diagramma a blocchi preliminare e un diagramma di flusso del software del vostro design. Una volta fatto tutto questo, non rimarrà che procurarvi i componenti, assemblarli e quindi creare e caricare il software per farli funzionare. SUGGERIMENTO Prima di mettervi a costruire qualcosa del genere, dovete assicurarvi di aver capito bene le considerazioni sulla sicurezza che implicano oggetti come un lanciarazzi. La National Association of Rocketry (NAR) e la Tripoli Rocketry Association hanno pubblicato delle linee guida per maneggiare e lanciare in modo sicuro i lanciarazzi. Inoltre, in molti stati esistono delle regole di base che riguardano dove e quando si possono effettuare lanci e che cosa definisce un lanciarazzi.
Il ciclo del design Quando progettiamo qualcosa con un grado anche solo moderato di complessità, è raro che non ci ritroviamo a ritornare a un passaggio precedente del processo per effettuare modifiche o cercare alternative. A volte questo può significare perfino buttare il design originale e ricominciare da capo. Non è infrequente. Il design è un processo iterativo e, man mano che avanza, diventa evidente quello che all’inizio non lo era. Anticipare tutto a priori è praticamente impossibile. Il processo di design segue la struttura generale che abbiamo presentato nel Capitolo 10. Cominciamo con una serie di obiettivi. Poi miglioriamo gli obiettivi per creare i requisiti funzionali. Grazie ai requisiti funzionali possiamo identificare i tipi di hardware e di software che soddisferanno i requisiti. Quindi analizziamo i dettagli dei componenti e delle tecniche che abbiamo selezionato per valutarne l’idoneità. La Figura 13-1 mostra come funziona il ciclo del design.
Figura 13-1 - Il ciclo del design.
Alla fine di ciascun passaggio, ci fermeremo e analizzeremo quello che abbiamo fatto fino a quel punto. Se ci fosse un problema, questo sarebbe il momento per decidere come risolverlo. A seconda del tipo e della gravità del problema, possiamo decidere di tornare indietro e rivedere il passaggio precedente, oppure possiamo decidere di rinunciare a qualcosa che non sia essenziale e procedere riducendo le nostre aspettative. Possiamo anche riscontrare dei problemi durante lo svolgimento di un passaggio in particolare. Immaginiamo, per esempio, di aver scoperto che una determinata shield, un sensore o un modulo semplicemente non si trovano e non possiamo costruircelo da soli. In questo caso, dovremmo fermarci, tornare indietro e vedere che cosa ci ha portato a quella decisione all’inizio e se possiamo cambiarla per adattarci alla situazione attuale. In alcuni casi, può non essere necessario costruire un vero prototipo. Questo spesso è il caso quando il design consiste principalmente di moduli già pronti, come in molti design basati su Arduino. A me piace costruire prototipi con piattaforme di prototipazione che
ho creato o acquistato, come il Duinokit e una breadboard che non richiede saldature che abbiamo visto nel Capitolo 10, oppure l’Arduino integrato che abbiamo utilizzato nei Capitoli 11 e 12. Questo mi permette di collegare le cose senza dover ricorrere a saldare fili e aprire fori, ottenendo comunque le stesse funzionalità che presenterebbe l’unità finita. In alcuni progetti di design, potete accorgervi che potete saltare il passaggio relativo alla prototipazione, ma dovete sapere che, se si presenta un problema nel design finale, affrontarlo può risultate costoso e richiedere molto tempo. NOTA In una situazione reale, il costo che comporta risolvere un difetto del design oppure dell’implementazione, che sia hardware o software, aumenta man mano che il progetto avanza lungo i passaggi mostrati nella Figura 13-1. In altre parole, è molto più economico risolvere un requisito funzionale non valido che riscrivere un software difettoso oppure affrontare un flusso di design dell’hardware. Allo stesso modo, è più facile e meno costoso affrontare un problema in un design che sta per entrare in produzione. Per questo i prototipi sono così diffusi.
Gli obiettivi Il primo passaggio per un design è decidere quali obiettivi deve poter raggiungere. All’inizio possiamo non disporre di tutti i dettagli, ma dobbiamo poter essere capaci di deciderne le caratteristiche fondamentali, anche se al principio sono soltanto alcune. L’elenco di obiettivi può allungarsi nel corso del tempo, a volte radicalmente. In effetti, mantenere gli obiettivi del design in linea con la realtà spesso diventa una sfida, specialmente quando chi definisce gli obiettivi non è la stessa persona che dovrà costruire il design finale. Fortunatamente, questo non è il nostro caso. Finché manterremo il nostro entusiasmo e il nostro ottimismo in linea con la realtà, staremo andando bene. Quando definite un elenco di obiettivi, vi consiglio di organizzarlo in base alla loro importanza. In altre parole, dobbiamo mettere le caratteristiche imprescindibili all’inizio dell’elenco e quelle che solo servono ad aggiungere dettagli alla fine. Questo ci permetterà di eliminare elementi dall’elenco se il livello di fatica, costo o tempo dovesse superare i limiti accettabili, senza perdere la funzionalità essenziale di quello che stiamo cercando di costruire. Ecco il mio elenco di obiettivi prioritari per un lanciarazzi automatico: 1. Il controller del lanciarazzi deve incorporare un timer per il conto alla rovescia con intervalli programmabili (5, 10, 15, 30 e 60 secondi). 2. Il conto alla rovescia deve poter essere interrotto in qualsiasi momento per diversi motivi (che spiegherò tra poco). 3. Il controller del lanciarazzi deve essere dotato di un interruttore di interblocco di sicurezza. Il lanciarazzi non inizierà il conteggio né attiverà gli accenditori a meno che l’interblocco di sicurezza non si trovi nella posizione “on”. 4. Il timer del contro alla rovescia deve essere attivato premendo un interruttore a pressione.
5. Il timer del contro alla rovescia non deve attivarsi a meno che un interruttore di sicurezza non venga sbloccato prima di premere il pulsante di avvio del conto alla rovescia e durante l’intera durata del conto. Questo può essere un ciondolo portatile o una piccola scatola e deve essere separato dall’interruttore che avvia il conto. 6. Se l’interruttore di sicurezza viene rilasciato prima del lancio, il conto alla rovescia si deve interrompere e il controller deve entrare in una modalità di sicurezza (con i circuiti dell’accenditore disattivati e messi a terra). 7. Il lanciarazzi deve essere in grado di alimentare diversi accenditori contemporaneamente. Due è il numero minimo, ma se è possibile possono essere fino a otto. 8. Ciascun accenditore deve poter essere monitorato indipendentemente da tutti gli altri, per poter rilevare problemi di continuità dei circuiti prima del lancio. 9. Un’interruzione di continuità in uno qualsiasi degli accenditori deve interrompere il lancio (la stessa risposta di quando si sblocca prima del tempo l’interruttore di sicurezza). 10. Il controller deve utilizzare un LED che lampeggia per tener traccia del conto alla rovescia in secondi. Altri indicatori LED devono mostrare lo stato del controller (caricato, conto alla rovescia in corso, interruzione di sicurezza o difetto degli accenditori). Gli obiettivi secondari sono questi: 1. Un display LED a 7 segmenti deve mostrare il conto alla rovescia. 2. Un display LED a 7 segmenti deve mostrare l’ora corrente. 3. Un LCD 16 2 deve mostrare i dati di stato del sistema e i messaggi di errore. 4. Tutti i componenti devono essere montati in un contenitore di basso profilo con un coperchio inclinato. E questi sono gli obiettivi facoltativi: 1. Il controller del lanciarazzi deve avere la capacità di attivare dispositivi esterni in determinati momenti della sequenza del conto alla rovescia, come scollegare la messa a terra, lanciare sirene di avvertimento e attivare componenti elettronici integrati sulla scheda (fotocamera e così via). 2. Il controller deve essere dotato di un connettore per collegare un display a 7 segmenti perché si possa mostrare un evento a un gruppo di persone. 3. Il controller deve incorporare la possibilità di generare una voce sintetica che annunci il conto alla rovescia e lo stato. 4. Un’interfaccia Bluetooth deve poter essere utilizzata per collegarsi a un sistema remoto di controllo delle condizioni meteorologiche (da utilizzarsi principalmente per rilevare la velocità del vento nella zona del lancio). Se lo si utilizza, il sistema
deve anche potersi interrompere in caso di velocità del vento eccessiva e indicarlo al direttore del lancio (l’utente). Questo è un elenco piuttosto vasto e ambizioso, a dire la verità. Raggiungere gli obiettivi principali non sembra troppo difficile, che è quello che deve succedere con gli obiettivi principali. Gli obiettivi secondari sono un può più complicati e quelli facoltativi, sebbene siano intriganti, possono gravare sulla resistenza della costruzione (oltre a comportare una spesa maggiore).
Selezionare e definire i requisiti funzionali Il modo in cui ho scritto gli obiettivi ci permette di passare direttamente ai requisiti funzionali con un breve passaggio. Un requisito deve essere chiaro, conciso, coerente e verificabile e in alcuni casi gli obiettivi sono definiti come requisiti, in modo che sia più facile per voi. La grande questione adesso è: quanti degli obiettivi possiamo confermare e trasformare in requisiti funzionali? Per poter rispondere a questa domanda, dobbiamo utilizzare un sistema di punteggio di qualche tipo per determinare quanto ciascun obiettivo sarà difficile, caro e necessario da raggiungere. Cominceremo dagli obiettivi principali. La Tabella 13-1 mostra un elenco di obiettivi principali con le mie migliori valutazioni in relazione a difficoltà, spesa e necessità complessive. Ciascun aspetto è valutato in base a una scala da 1 a 5, dove 1 è la valutazione più bassa e 5 la più alta. Tabella 13-1 - La valutazione degli obiettivi principali.
Obiettivo
Difficoltà
Costo
Necessità
1.1
2
2
2
1.2
3
2
5
1.3
3
2
5
1.4
2
2
4
1.5
2
3
5
1.6
2
1
5
1.7
3
3
3
1.8
4
3
5
1.9
3
2
5
1.10
3
2
2
Da qui possiamo concludere che, se necessario, l’obiettivo 1.1, il timer del conto alla rovescia programmabile, può essere sostituito da un conteggio fisso di 10 o 15 secondi. Risulta anche evidente che l’obiettivo 1.10, le luci lampeggianti, può ricadere nella categoria dei “capricci”, o degli obiettivi secondari, e se necessario può essere omesso (anche se probabilmente vorremo mantenere almeno il LED del conto alla rovescia perché ci faccia sapere che sta succedendo qualcosa). Possiamo fare lo stesso per gli obiettivi secondari e facoltativi, come mostra la Tabella 13-2. Tabella 13-2 - La valutazione degli obiettivi secondari e facoltativi.
Obiettivo
Difficoltà
Costo
Necessità
2.1
3
3
2
2.2
3
3
2
2.3
3
3
2
2.4
3
3
2
3.1
4
4
1
3.2
4
3
1
3.3
4
4
1
3.4
4
4
1
Potete notare che tra la Tabella 13-1 e la Tabella 13-2 emerge un pattern interessante. Gli obiettivi principali sono tutti relativamente poco cari e facili da implementare. Inoltre, con le eccezioni di 1.1 e 1.10, sono tutti necessari. Nella Tabella 13-2 vediamo che, man mano che crescono la spesa e la difficoltà, decresce la necessità. Nessuno degli obiettivi facoltativi è necessario, anche se tutti sarebbero molto divertenti da implementare. No ho organizzato gli obiettivi intenzionalmente quando li ho scritti, ma mi sono venuti in quest’ordine. Immagino che possa essere il risultato del fatto che faccio cose di questo genere da diversi anni, ma in ogni caso a voi converrà organizzare i vostri obiettivi innanzitutto sulla base della necessità e poi sulla base di costo o difficoltà, a seconda di che cosa è più importante per voi: se il denaro o il tempo. Si deve arrivare a un compromesso. Se qualcosa è necessario ma anche caro, dobbiamo eliminare qualcosa che non sia necessario per non elevare il costo del progetto, oppure possiamo decidere di investire più denaro per raggiungere entrambi gli obiettivi? In alcuni casi, come quando ci tocca scegliere tra obiettivi principali e obiettivi facoltativi, la decisione è chiara. Il risultato finale può non essere entusiasmante come sarebbe stato altrimenti, ma nemmeno potremo andare in bancarotta per ottenerlo. Lancerà comunque bene i razzi. Quando invece dobbiamo scegliere tra due obiettivi principali, con lo stesso livello di necessità e lo stesso costo, come gli obiettivi 1.1 e
1.10, la scelta può dipendere da quanto sono difficili gli obiettivi. In questo caso, probabilmente installare un interruttore rotativo per selezionare la durata del conto alla rovescia sarebbe più facile che aprire dei buchi per dei LED, collegarli e installarli e poi creare il software necessario per controllarli. Per amor di continuità con l’analisi del design, immaginiamo di voler mantenere tutti gli obiettivi in modo da poter vedere come influenzeranno il design e la selezione dei componenti nei prossimi passaggi. La Tabella 13-3 elenca i requisiti funzionali derivati dagli obiettivi. Tabella 13-3 - I requisiti funzionali del lanciarazzi.
Req
Descrizione
1.1
Il controller del lanciarazzi deve incorporare un timer per il conto alla rovescia. Quando questo arriva a zero, viene/vengono attivato/i l’/gli accenditore/i.
1.1.1
Il timer del conto alla rovescia deve avere tre durate programmabili di 5, 10, 15, 30 e 60 secondi.
1.1.2
Le durate del conto alla rovescia devono essere selezionate utilizzando un interruttore rotativo da cinque posizioni.
1.1.3
Se la durata del conto alla rovescia viene cambiata a metà strada, il conto alla rovescia si deve interrompere.
1.2
Il conto alla rovescia deve poter essere interrotto in qualsiasi momento per diverse ragioni (spiegate tra poco).
1.2.1
Il conto alla rovescia deve essere interrotto se un circuito di un accenditore che dovrebbe essere chiuso è aperto (vedere 1.7.1 e 1.9.1).
1.2.2
Il conto alla rovescia deve essere interrotto se la durata del conto cambia mentre è attivo il conto alla rovescia.
1.2.3
Il conto alla rovescia deve essere interrotto se l’interruttore di sicurezza viene rilasciato durante il conto.
1.3
Il controller del lanciarazzi deve essere dotato di un interruttore di interblocco di sicurezza a inserimento.
1.3.1
Il lanciarazzi non deve attivare il conteggio o attivare gli accenditori a meno che l’interruttore di sicurezza non si trovi nella posizione “on”.
1.3.2
Il conto alla rovescia deve interrompersi se l’interruttore di sicurezza è impostato su off durante il conto alla rovescia.
1.4
Il timer del conto alla rovescia deve essere attivato premendo un interruttore a pressione.
1.4.1
Per attivare il conto alla rovescia si deve utilizzare un pulsante di lancio.
1.4.2
Il pulsante di lancio non deve poter funzionare a meno che l’interruttore range
safety non sia attivato. 1.5
Il lanciarazzi deve utilizzare un interruttore range safety per controllare il conto alla rovescia e il lancio.
1.5.1
Il conto alla rovescia del lancio non può avanzare a meno che un interruttore di sicurezza non venga disattivato prima della pressione del pulsante di lancio.
1.5.2
L’interruttore range safety deve essere attivato manualmente durante l’intera durata del conto alla rovescia.
1.5.3
L’interruttore range safety può essere un ciondolo portatile o una piccola scatola e deve essere dotato di almeno 10 piedi (3 m) di cavo elettrico.
1.6
Se il conto alla rovescia viene interrotto per qualsiasi ragione, il lanciarazzi deve entrare nella modalità di sicurezza.
1.6.1
Nella modalità di sicurezza, tutte le linee degli accenditori devono essere disattivate e messe a terra.
1.6.2
Per uscire dalla modalità di sicurezza deve essere necessario disarmare il lanciarazzi utilizzando l’interruttore di sicurezza.
1.7
Il lanciarazzi deve essere in grado di attivare diversi accenditori contemporaneamente.
1.7.1
Il lanciarazzi deve poter supportare fino a sei circuiti attivi degli accenditori.
1.7.2
Per selezionare il numero di circuiti attivi degli accenditori si deve utilizzare un interruttore rotativo.
1.8
Ciascun accenditore deve poter essere monitorato indipendentemente dagli altri per poter rilevare problemi di continuità dei circuiti prima del lancio.
1.8.1
Ciascun circuito degli accenditori deve avere continuità per permettere di verificare che l’accenditore sia collegato.
1.8.2
La corrente utilizzata per determinare la continuità non deve eccedere i 250 uA su ciascun circuito degli accenditori.
1.9
La mancanza di continuità di uno qualsiasi degli accenditori deve interrompere il timer del conto alla rovescia.
1.9.1
Il conto alla rovescia non deve iniziare se uno qualsiasi dei circuiti degli accenditori non ha continuità.
1.9.2
Il conto alla rovescia si deve interrompere se uno qualsiasi dei circuiti attivi degli accenditori perde continuità durante il conto.
1.9.3
Il lanciarazzi deve utilizzare dei LED per indicare i circuiti attivi e pronti (vedere 1.1.2).
1.10
Il controller deve utilizzare dei LED per indicare il conto alla rovescia e lo stato.
1.10.1
Un LED lampeggiante deve tener traccia del conto alla rovescia in secondi, un lampeggiamento al secondo.
1.10.2
Una serie di LED deve mostrare lo stato attivo e la continuità dei circuiti degli accenditori.
1.10.3
Un LED deve indicare lo stato attivo dell’interruttore range safety.
1.10.4
Un LED deve indicare un range safety abort.
1.10.5
Un LED deve indicare lo stato dell’interblocco di sicurezza.
1.10.6
Un LED lampeggiante deve indicare quando il lanciarazzi si trova nella modalità di sicurezza dopo un’interruzione.
2.1
Un display LED a 7 segmenti deve mostrare il conto alla rovescia.
2.1.1
Un display LED rosso da 2 cifre e a 7 segmenti deve mostrare il conto alla rovescia.
2.1.2
Il conto alla rovescia deve mostrare dei trattini dopo che un lancio è avvenuto correttamente.
2.1.3
In caso di interruzione, il display deve mostrare la parola “Abort”.
2.2
Un display LED a 7 segmenti deve mostrare l’ora corrente.
2.2.1
Un display LED giallo da 4 cifre e a 7 segmenti con formato OO:MM deve mostrare l’ora corrente.
2.2.2
Il display dell’ora deve poter essere configurato utilizzando un pulsante sul pannello anteriore del lanciarazzi.
2.2.3
Il display dell’ora deve essere nel formato da 24 ore.
2.3
Un display LCD 16 × 2 deve mostrare i dati relativi allo stato del sistema e i messaggi di errore.
2.3.1
Un display LCD 16 × 2 deve mostrare i messaggi di stato e i problemi.
2.3.2
Il display LCD deve anche poter mostrare messaggi provenienti da sorgenti esterne come una stazione meteorologica remota.
2.4
Tutti i componenti devono essere montati in uno chassis di basso profilo con coperchio inclinato.
2.4.1
Per contenere il lanciarazzi deve essere utilizzato uno chassis di metallo di basso profilo.
2.4.2
Lo chassis deve essere almeno largo 14 pollici e profondo 10 pollici (35,5 × 25,5 cm), con un’altezza di 1,5 pollici nella parte anteriore e di 3 pollici in quella posteriore (3,8 × 7,6 cm).
3.1
Il controller del lanciarazzi deve avere la possibilità di attivare dispositivi esterni in determinati momenti del conto alla rovescia.
3.1.1
Il controller deve essere capace di attivare dispositivi esterni per mezzo di relè in punti del conto alla rovescia che definisce l’utente.
3.1.2
I punti d’azione devono poter essere impostati utilizzando un collegamento USB con l’Arduino sul lanciarazzi.
3.2
Il controller deve essere dotato di un connettore per collegare un grande display a 7 segmenti per mostrare un evento a un gruppo di persone.
3.2.1
I segnali diretti al display interno da due cifre del conto alla rovescia devono essere duplicati a un connettore sulla parte posteriore dello chassis.
3.2.2
I segnali del display esterno devono essere controllati da un IC ad alta tensione che fornisca corrente sufficiente.
3.3
Il controller deve incorporare la possibilità di generare una voce sintetica che annunci il conto alla rovescia e lo stato.
3.3.1
Il lanciarazzi deve incorporare una shield di sintesi vocale per produrre una voce che si possa capire.
3.3.2
L’output della voce deve poter essere definito dall’utente.
3.4
Per collegare una stazione meteorologica remota, si deve utilizzare un’ interfaccia Bluetooth.
3.4.1
L’utente deve poter definire un limite massimo per la velocità del vento. Se la velocità del vento lo supera, il lancio si deve interrompere automaticamente.
3.4.2
Un LED sul pannello anteriore deve indicare che il lancio è stato interrotto per via di un’eccessiva velocità del vento.
Ho cercato di mantenere una relazione uno-a-uno con gli obiettivi elencati in precedenza, ma c’è qualche deviazione, principalmente per evitare la ridondanza. SUGGERIMENTO Il design utilizza un “interruttore range safety” che deve essere tenuto premuto (attivo) durante il conto alla rovescia. Questa è una funzionalità di sicurezza essenziale. Nella pratica, devono essere coinvolte due persone: un direttore del lancio e un addetto alla sicurezza. E a quest’ultimo che tocca interrompere il lancio se qualcosa non è come dovrebbe essere prima dell’accensione (per esempio, c’è troppo vento o gente nella zona di lancio).
Creare il design preliminare Adesso che abbiamo definito i requisiti funzionali, possiamo vedere alcuni ovvi criteri di design. Sappiamo che avremo bisogno di due interruttori rotativi, di un display LCD, di due display a 7 segmenti, di un orologio in tempo reale di un qualche tipo, di un ciondolo o di una scatolina con un interruttore a pulsante (l’interruttore range safety), di alcuni connettori sul pannello posteriore, di alcuni relè e di veri LED di diversi colori.
Per farci un’idea migliore di che cosa sarà coinvolto nel design, possiamo creare un diagramma a blocchi preliminare come quello mostrato nella Figura 13-2. Osservando il diagramma a blocchi, notiamo immediatamente che qualcosa come un Arduino Uno non sarebbe in grado di gestire tutti gli I/O necessari. Dobbiamo quindi orientarci su un Mega2560. Possiamo anche decidere di utilizzare più di un Arduino che si suddividano il carico.
Figura 13-2 - Il diagramma a blocchi preliminare del lanciarazzi.
La Figura 13-3 è una versione più raffinata del diagramma a blocchi. Notiamo che utilizza un Uno per la sintesi vocale, un altro per il Bluetooth e un Mega2560 per le funzioni di controllo principali. La MCU ATmega2560 utilizzata nel Mega2560 è dotata di diverse interfacce USART, per cui ciascuna delle schede Uno può disporre del suo proprio canale di comunicazione dedicato.
Figura 13-3 - Il diagramma a blocchi perfezionato del lanciarazzi.
Nella Figura 13-3, diverse delle interfacce per i moduli esterni sono state perfezionate e assegnate come tipi I2C. Inoltre, sono state identificate le porte I/O digitali (DIO). Per gestire i relè e i 12 LED di stato degli accenditori, è stato scelto un expander I/O (simile a quello che abbiamo utilizzato nello Switchinator nel Capitolo 10).
Costruire o acquistare A un certo punto, quando ci si avventura in progetti moderatamente complessi, diventa necessario scendere a compromessi per decidere se acquistare un modulo hardware già pronto oppure progettarne e costruirne uno tagliato su misura per i requisiti specifici del design. Questa decisione può risultare difficile e non riguarda soltanto i costi. Un componente o un modulo COTS (commercial off-the-shelf) può essere dotato o meno di tutte le funzionalità delle quali abbiamo bisogno per il nostro design. Può disporre delle funzioni corrette, ma dei connettori sbagliati, o viceversa. Può essere della dimensione sbagliata, oppure soltanto leggermente fuori misura su un lato o sull’altro. Può perfino richiedere una tensione diversa da quella di tutti gli altri componenti del design e richiedere ulteriori circuiti per adattarlo.Quindi, ha senso adattare il design del componente COTS, oppure sarebbe meglio costruire un componente personalizzato che sia esattamente quello di cui abbiamo bisogno? Se la modifica richiesta dal modulo è minima, probabilmente conviene semplicemente adattarlo, piuttosto che spendere tempo e denaro per un design personalizzato. Se invece il problema è più serio, come le dimensioni fisiche o funzioni
non necessarie che produrranno conflitti, ha molto più senso costruire il componente a partire da un design pulito e mantenerlo coerente con il resto dei componenti. Se non siete sicuri, di solito la decisione emerge valutando il costo e il tempo necessario per utilizzare il componente COTS e confrontandoli con quelli necessari per costruire una parte personalizzata. Se continua a essere difficile, per decidere per che cosa votare si possono utilizzare altri criteri: di quanto controllo abbiamo realmente bisogno sulla produzione e sulle funzioni interne del componente in questione? Se stiamo costruendo un prodotto commerciale e c’è la possibilità che il modulo COTS che vogliamo utilizzare venga abbandonato mentre il nostro prodotto è ancora in produzione, ci conviene decidere di costruircelo da soli. Analogamente, se abbiamo bisogno di visibilità sul funzionamento interno del componente COTS ma per noi è una “scatola nera”, ci conviene decidere di costruirne una versione personalizzata.
La fattibilità del design Quindi, quanto è realistico il design che ci è venuto in mente? Abbastanza? Sì, senza dubbio. È eccessivo? Forse. Adesso è il momento di tornare indietro e di rivedere il design preliminare con occhio critico, disposti a rinunciare a tutte le funzionalità meno necessarie e più frivole senza rimorsi e senza rimpianti.
Le funzionalità accessorie In ingegneria, per descrivere funzionalità che in realtà non contribuiscono al funzionamento di un sistema, ma aggiungono soltanto un po’ di sale sul prodotto finale, spesso si utilizza l’espressione inglese “bells and whistles”. Un esempio può essere un display TFT a colori su una macchina per il caffè. Aiuta realmente il dispositivo a fare il caffè più buono? No, naturalmente no. Si presenta elegante e high-tech in cucina? Sì, ed è per questo che è lì ed è per questo saremmo disposti a pagare la macchina del caffè un po’ di più. Considerate questo: le automobili moderne sono piene di accessori. Tutto quello che è necessario in una macchina in realtà sono soltanto quattro ruote, un motore, qualche sedile e delle finestre per proteggere i passeggeri da pioggia, vento e polvere. In realtà, nessuno ha bisogno di un sound system da 10 altoparlanti, di un telefono cellulare in vivavoce, di un sistema di navigazione e di sedili elettrici da varie posizioni soltanto per andare a fare la spesa, giusto? Un’automobile essenziale senza tutti questi accessori può essere brutta da vedere, ma vi porterà lo stesso dove volete o dove dovete andare. Inoltre, questa automobile semplice e brutta probabilmente starà ancora funzionando mentre l’altra piena di accessori passerà il suo tempo presso la concessionaria nel reparto dedicato alle riparazioni. La conclusione è che le cose più semplici non soltanto sono meno care, ma tendono anche a essere più affidabili, perché contengono meno componenti che si possono rompere. Quindi, quando rivediamo la fattibilità di un design, è importante prestare attenzione a ben più che soltanto alla sua fattibilità tecnica. Dobbiamo controllare anche gli accessori che in realtà non contribuiscono al funzionamento del dispositivo, ma possono contribuire al fatto che smetta presto di funzionare.
La fattibilità è una valutazione relativa. In altre parole, fattibile in relazione a cosa? Alcune cose possono non essere fattibili per qualcuno che lavora sul tavolo della cucina ed esserlo perfettamente per un’altra persona che ha accesso a tutto il negozio. Il budget disponibile è un’altra questione importante, dal momento che rappresenta un limite. Una persona con poca disponibilità economica e poco tempo non può sperare di ottenere lo stesso di qualcun altro dotato di una generosa quantità di denaro da spendere e molto tempo libero. Dal momento che io solo soltanto una persona con poco tempo libero e soltanto una piccola quantità di risparmi a mia disposizione, devo essere prudente rispetto a quanto posso ottenere e a quanto velocemente posso aspettarmi di ottenerlo.
E sono sicuro di non essere il solo. Quando valuto la fattibilità di un design e delle sue funzionalità, mi piace utilizzare questi cinque criteri: •
La funzionalità o il design ha senso dal punto di vista funzionale?
•
Ha senso dal punto di vista del costo?
•
C’è qualche componente che può essere difficile da trovare?
•
La funzionalità o il design presenta qualche aspetto che non è sicuro? Può essere assemblato, programmato e testato da una sola persona in un periodo di tempo ragionevole?
Se la risposta anche solo a una di queste domande è no, o addirittura forse, significa che il componente o la funzionalità del design in questione deve essere candidata all’eliminazione. Il design del lanciarazzi, come rappresentato nella Figura 13-3, sarebbe davvero una cosa meravigliosa, ma non credo che sia qualcosa che io possa aspettarmi di portare a termine in un periodo di tempo ragionevole. Il miglior approccio potrebbe essere mantenerlo semplice (più semplice possibile, comunque) e creare un design che possa essere espanso in futuro. Per via del modo nel quale abbiamo organizzato gli obiettivi del lanciarazzi, ridurre il design è piuttosto facile. I requisiti funzionali di livello 3 definiscono cose che richiedono sia molto tempo che molto denaro. Inoltre, non contribuiscono in nessun modo essenziale alla funzionalità chiave del lanciarazzi, che naturalmente è lanciare modellini di razzi. Per questo, ho deciso di designare tutti i requisiti funzionali di livello 3 come funzionalità opzionali da aggiungere in eventuali future implementazioni. Chiameremo il lanciarazzi essenziale, che è formato dai requisiti funzionali di livello 1 e di livello 2, la versione Fase I. Possiamo fare riferimento al design esteso come versione Fase II. Anche se stiamo pensando al design della Fase I, possiamo cercare già dei modi per semplificare ulteriormente il design senza sacrificare nessuna delle funzionalità necessarie. Per esempio, nella Figura 13-3 c’è un expander I/O. Che cos’è? Può essere qualcosa come una shield d’espansione I/O Centipede, descritta nel Capitolo 8. La Centipede ha 64 linee I/O digitali e quindi una di queste può facilmente gestire i LED di stato degli accenditori, i 4 LED di stato del sistema e i 2 interruttori rotativi. Possiamo ulteriormente semplificare il cablaggio utilizzando il più possibile SPI e I2C. L’RTC, l’LCD 16 × 2 e l’expander I/O sono tutti disponibili con interfacce I2C e moduli display a 7 segmenti per il conto e i display dell’ora sono disponibili con interfacce SPI. Il diagramma a blocchi rivisto per la Fase I è mostrato nella Figura 13-4.
Figura 13-4 - Il diagramma a blocchi della Fase I.
Io ho scelto di lasciare i relè per il controllo del lancio collegati ai pin I/O digitali discreti della Mega2560, anziché guidarli per l’expander I/O. In questo modo, non c’è niente tra i relè del lancio e l’Arduino che li controlla. Probabilmente non farà una grande differenza, ma elimina una potenziale fonte di guasto dalla pista di controllo principale del lanciarazzi. Lo stesso ragionamento è il motivo per il quale l’avvio del conto, l’interruttore range safety e quello per armare il sistema sono collegati direttamente all’Arduino. Inoltre, collegando gli interruttori direttamente potremmo approfittare della capacità di interrupt dei pin della MCU AVR, se volessimo. Il diagramma mostrato nella Figura 13-4 è quello che utilizzeremo per procedere. A un certo punto del futuro, potrebbe diventare fattibile provare la Fase II, ma per il momento no. Rimarrà lì, in attesa del momento nel quale potrà tradursi in realtà.
L’elenco preliminare dei componenti Con un design preliminare sotto mano per la versione Fase I, disponiamo di abbastanza informazioni da poter assemblare un elenco preliminare di parti. Riguardando i requisiti funzionali e contando il numero di volte nel quale sono menzionati vari tipi di controlli e di
funzioni, possiamo farci una prima idea delle quantità che ci serviranno. L’elenco preliminare dei componenti non include cose come le PCB del prototipo per fare il patching del cablaggio e montare piccole morsettiere (come quelle mostrate nel Capitolo 11). Questi requisiti possono essere scoperti e documentati quando viene il momento di collegare il tutto in un’unità funzionante, che sia un prototipo o la versione finale. Tabella 13-4 - L’elenco preliminare dei componenti del lanciarazzi.
Quantità
Descrizione
1
Arduino Mega2560
1
Display LED a 7 segmenti e 2 cifre
1
Shield con terminali a vite Mega
1
Display LED a 7 segmenti da 4 cifre per l’ora
1
Shield display LCD
1
Interruttore Keyed
1
Modulo RTC (Real-time clock)
1
Grande interruttore a pressione
2
Moduli con quattro relè
1
Chassis di metallo con coperchio inclinato
Il prototipo Come abbiamo visto prima, un prototipo serve per diversi scopi importanti. Prima di tutto, permette di lavorare con il design e con i suoi componenti in una forma flessibile e facile da modificare. Se un modulo o un sensore non funziona come pensavamo che funzionasse, nel prototipo è molto più facile cambiarlo di quanto non sarebbe aprire ulteriori fori in uno chassis di metallo. Secondo, nel caso di design che richiedono una PCB personalizzata (o due o tre), ci sarà un lasso di tempo tra il momento in cui si invia il progetto della PCB e quello in qui arrivano le schede finite e si può iniziare il montaggio. Se stiamo costruendo un prototipo, questo lasso di tempo può essere sfruttato lavorando sul software o sulla documentazione, oppure su entrambi. Infine, in alcuni casi possiamo avere a disposizione già tutto quello che ci serve per il prototipo e portarlo al punto nel quale può servire come sostituto del prodotto finale è relativamente semplice. La Figura 13-5 mostra un semplice prototipo con un Arduino Mega2560 costruito a partire da alcune sezioni tagliate da una tavola di pino.
Figura 13-5 - Il prototipo della Mega2560.
I prototipi possono definitivamente far risparmiare molto tempo ed evitare molti problemi, ma, come ho detto prima, a volte questo passaggio può essere saltato. Nel caso del modellino di lanciarazzi, abbiamo un design che dal punto di vista fisico non è eccessivamente complesso, non ci sono PCB personalizzate da progettare e tutti i componenti sono componenti COTS ben noti. Se volete, potete certamente costruire un prototipo. Se prevedete di incorporare gli obiettivi facoltativi, un prototipo è probabilmente una buona idea. Potete montare tutte le parti su una scheda grande e assicurarvi che tutto funzioni come vi aspettate, prima di inserirlo in una custodia di metallo. Un tagliere da cucina probabilmente presenterà le giuste dimensioni. Questo, a proposito, è da dove viene il termine “breadboard”, nel caso ve lo siate mai chiesto. Montare schede Arduino, morsettiere e altre cose di vario genere su una scheda fa parte di una lunga tradizione che risale ai tempi della radio all’inizio del XX secolo. Coloro che sperimentavano con la radio utilizzavano letteralmente taglieri per il pane, come quelli che si trovano nelle cucine, come base per i terminali, gli zoccoli delle valvole e altri componenti. A volte attaccavano uno schema sul tagliere, per offrire al costruttore qualcosa da seguire. Molte delle prime radio erano fatte principalmente di legno e la base per i componenti non era molto diversa dalle breadboard che si utilizzavano per prototipare e testare le radio ai loro inizi. Ma anche se le breadboard hanno un passato storico, per questo studio di design darò per scontato che passeremo direttamente all’unità finale (per esempi di prototipi, potete consultare i tre capitoli precedenti). Per il lanciarazzi abbiamo una buona serie di requisiti funzionali Fase I e sappiamo quali componenti principali ci serviranno. Quindi, possiamo passare all’hardware finale e al design del software.
Il design finale Il design finale è dove applichiamo i requisiti funzionali, insieme a quello che abbiamo imparato dal prototipo (se ne abbiamo creato uno), per arrivare a un design che descrive come deve apparire il dispositivo finito e come deve funzionare. Idealmente, deve comportarsi esattamente come il prototipo e il software deve essere lo stesso o quasi uguale.
Gli aspetti elettrici Lo schema mostrato nella Figura 13-6 illustra tutti i circuiti del lanciarazzi eccetto quello per controllare la continuità degli accenditori, che è mostrato nella Figura 13-7. Notate che l’RTC, il display LCD e la shield d’espansione I/O utilizzano tutti l’interfaccia I2C. I due display a 7 segmenti utilizzano l’interfaccia SPI. Soltanto i relè utilizzano output discreti digitali.
Figura 13-6 - Lo schema finale della Fase I.
Figura 13-7 - I circuiti di controllo della continuità degli accenditori.
Un tipico accenditore per modellini di razzi richiede circa 0,5 A o più per l’accensione. Per determinare se il circuito dell’accenditore è aperto o chiuso misurando la tensione nel punto etichettato come “sense”, possiamo utilizzare un circuito come quello mostrato nella Figura 13-7. La questione principale è rilevare lo stato aperto o chiuso dell’accenditore senza applicare abbastanza corrente da causarne l’accensione. Con questo circuito, nell’accenditore scorrono soltanto circa 2 mA e il diodo Zener da 4,9 V impedisce alla tensione per il lancio completo di tornare negli input analogici di Arduino. NOTA Sono stati ideati altri circuiti di controllo della continuità degli accenditori, alcuni più complessi di altri (sembra che esista una serie di piccole attività domestiche che si dedicano a creare controller di lanciarazzi e circuiti per testare la continuità dei modellini di razzi). Se volete saperne di più, una fonte di informazioni è lo studio dettagliato di tecniche di test di continuità degli accenditori (http://bit.ly/brohm-igniter) di J. R. Brohm.
Nello schema mostrato nella Figura 13-6, sei circuiti di continuità sono collegati a sei input analogici della Mega2560 con etichetta “Igniter Continuity Sense”. Per questo, vi suggerisco che i sei circuiti identici siano costruiti utilizzando una scheda di prototipazione e alcune morsettiere da 0,1 pollici (2,54 mm), analogamente a quello che abbiamo fatto per la protezione degli input nel Capitolo 11. Per collegare gli accenditori al controller del lanciarazzi possiamo utilizzare alcuni morsetti come quelli del tipo che si utilizza per collegare gli altoparlanti agli stereo di alta gamma. Vi suggerisco anche di utilizzare questi morsetti per collegare una batteria esterna. Se volete aggiungere delle batterie nello chassis del controller del lanciarazzi, potete utilizzare un’ulteriore coppia di morsetti per collegare le batterie interne ai circuiti dell’accenditore. Questo vi
permetterà di scegliere quale sorgente di alimentazione utilizzare, a seconda del numero di circuiti degli accenditori che saranno attivi. Nella Figura 13-8 è mostrato come si collegano i circuiti per controllare la continuità degli accenditori con i morsetti degli accenditori.
Figura 13-8 - Collegare i circuiti per rilevare gli accenditori.
L’idea che sta dietro ai 12 LED collegati all’expander I/O ed etichettati come “Igniter Continuity Indicators” e “Igniter Select Indicators” nella Figura 13-6 è mostrare quanti circuiti degli accenditori sono attivi e in quale stato si trovano in un dato momento. Questo è determinato dall’interruttore rotativo da sei posizioni S6, con le impostazioni 1, 2, 3, 4, 5 e 6. Il LED di continuità corrispondenti si illumineranno per indicare che gli accenditori selezionati sono collegati e pronti. Dopo il lancio, i LED di continuità devono essere spenti e devono rimanere accesi soltanto i LED della selezione attiva. La Figura 13-9 mostra una vista diversa del collegamento, con un’enfasi sugli output dell’accenditore, i moduli a scheda perforata per i circuiti dei LED e pull-up e l’alimentazione DC che collega i vari moduli. Notate che le singole linee di segnale per I2C, SPI e le funzioni DIO e AIN non sono mostrate. Invece, la notazione dei bus, che consiste di una barra con un numero, è utilizzata per indicare quanti segnali discreti sono chiamati in causa. Negli schemi non sono mostrate neanche cose come le morsettiere per l’alimentazione e la messa a terra.
Figura 13-9 - Diagramma di collegamento dello chassis.
Un punto interessante nella Figura 13-9 è l’uso di uno dei relè sul secondo modulo relè come interruttore di sicurezza per l’accensione. A meno che il relè non sia attivo, gli accenditori non ricevono alimentazione. Notate anche che ci sono quattro moduli a scheda perforata utilizzati per fissare i circuiti di rilevamento della continuità degli accenditori e resistenze pull-up per vari LED e interruttori. L’utilizzo delle morsettiere pitch da 0,1 pollici (2,54 mm) rende i cablaggi del sistema molto più facili delle saldature e inoltre questi, se necessario, in futuro possono essere rimossi e sostituiti. Con gli schemi sotto mano, adesso possiamo creare un elenco dettagliato di componenti come quello della Tabella 13-5. Tabella 13-5 - L’elenco di parti del lanciarazzi finale.
Quantità
Descrizione
1
Arduino Mega2560
1
Grande interruttore a pressione
1
Shield Mega con terminali a vite
8
Morsetti rossi
8
Morsetti neri
1
Shield display LCD
1
Modulo RTC (Real-time clock)
1
Jack da 3,5 mm (circuito singolo)
2
Moduli da quattro relè
1
Supporto per le batterie, sei celle D
1
Display LED a 7 segmenti da 2 cifre
1
Chassis di metallo con coperchio inclinato
1
Display LED a 7 segmenti da 4 cifre per l’ora
1
Interruttore Keyed
Gli aspetti fisici Vi consiglio di costruire il lanciarazzi in uno chassis di metallo inclinato. Anche se a quanto pare questo specifico contenitore non è più disponibile, può andarne bene un altro simile a quello mostrato nel disegno della Figura 13-10. Questo è il disegno di un vecchio chassis che si trova nel mio laboratorio da tempo e dal quale molto tempo fa ho estratto i componenti elettronici che conteneva. Lo chassis è un design di due parti che è largo 14 pollici (35,6 cm), profondo 10 pollici (25,4 cm) e alto 1,5 pollici (3,8 cm) davanti e 2,75 pollici (7 cm) dietro. È dotato anche di uno “scaffale” piatto da 3,5 pollici (8,9 cm) in alto nella parte posteriore del coperchio. Attualmente è troppo brutto per fotografarlo e quindi vi basti un disegno.
Figura 13-10 - Lo chassis candidato per il lanciarazzi.
Non è uno chassis all’ultimo grido, assolutamente. È soltanto una cosa che avevo a portata di mano. Voi potete disporre di qualcosa di altrettanto adatto, oppure potete aver accesso a un outlet di surplus di componenti elettronici. Se questo è il vostro caso, potete acquistare uno chassis carino e simile a questo presso diversi distributori. Potete aspettarvi di pagarlo tra i 30 $ e i 50 $. Dopo aver scelto la custodia, il prossimo passaggio è decidere il layout del pannello anteriore e dove posizionare le schede e i connettori. Con uno chassis come quello
mostrato nella Figura 13-10, vi consiglio di montare il più possibile all’interno del pannello superiore. Il motivo principale è evitare di far correre fili tra le schede e i controlli nel pannello superiore. Dal momento che la parte posteriore dello chassis non è altro che la continuazione di quello superiore, non dovete preoccuparvi di scollegare le cose se dovete rimuovere il pannello superiore per prendere qualcosa al suo interno. La Figura 13-11 mostra un layout per il pannello. Questo è soltanto un modo di farlo e potete optare per un’organizzazione diversa. La shield d’espansione I/O ha moltissimi punti I/O (64 in tutto) e quindi rimane disponibile moltissimo spazio per crescere.
Figura 13-11 - Un esempio di layout del pannello dei controlli del lanciarazzi.
Di nuovo, vi consiglio di montare tutti i componenti all’interno del coperchio, eccetto forse le eventuali batterie. Questo rende più facile assemblare e testare il lanciarazzi senza dover anche trascinare la base e una serie di fili per collegare i componenti superiori e inferiori. Lo svantaggio è che alla fine vi ritroverete con le teste delle viti sul pannello anteriore, ma potete sempre dipingerle oppure utilizzare viti a testa piatta (se il metallo del pannello è abbastanza spesso). Se dovessi realmente costruirlo (e dovrei, visto che ci ho lavorato tanto), monterei la Mega2560 e la shield I/O sotto la sezione piatta della parte superiore dello chassis. Questo è uno spazio ampio 3,5 pollici (8,9 cm), più che abbastanza per accogliere un Arduino (o due) senza interferire con i controlli e i display sul pannello anteriore. Un modo per avere tutto sistemato dove vogliamo è creare un mockup utilizzando modelli di varie schede e moduli fatti di cartone o di materiale a nucleo di schiuma con qualche etichetta adesiva. Possiamo ritagliare delle forme con le stesse dimensioni delle parti reali e utilizzare alcune etichette adesive rotonde come segnaposto per gli
interruttori e i LED. Quindi possiamo sistemare i modelli su un pezzo di carta con un contorno rettangolare come quello del pannello per cercare la sistemazione ottimale. Io lo farei come se fossi dotati di vista a raggi X e stessi guardando attraverso il pannello. In questo modo, non dovrei girare le cose mentalmente per visualizzare dove devono andare i LED e i display LCD, oppure dove devono essere posizionati i LED e gli interruttori. Possiamo prendere le misure direttamente sul mockup e creare uno schema di produzione come quello mostrato nel Capitolo 11 (naturalmente, se per caso siete appassionati di strumenti CAD, potete semplicemente saltare dritto allo schema di produzione e saltare il passaggio dei modelli). Potete anche decidere di collegare il connettore USB della Mega2560 al connettore di tipo B montato sul pannello posteriore. Questo può essere utilizzato per aggiornare il software, catturare dati operativi durante i lanci, o perfino fungere da display in tempo reale che può essere inviato in un’aula perché tutti lo possano vedere.
Il software Nel caso di uno studio di design come questo, per lo più il software è soltanto qualche suggerimento e qualche diagramma a blocchi. Lo scopo principale è determinare il livello complessivo di sforzo in relazione al numero di funzioni supportate dal software. Se è progettato e implementato rispettando i requisiti funzionali, dobbiamo poter mappare la funzionalità del software direttamente sui requisiti. Inoltre, non dovremmo avere funzionalità che non sono definite nei requisiti. Nell’industria, specialmente quella aerospaziale, questo è considerato un male, dal momento che la funzionalità del software senza un requisito previo è una funzionalità che non potrà essere completamente testata, se mai potrà esserlo del tutto. E il software non testato è rischioso. Dal momento che questo è un tipico design di tipo Arduino, le funzioni setup() e loop() risiederanno in un modulo principale. Avremo bisogno anche di una selezione di variabili globali che contengano i vari dati di stato e ora. La funzione loop() dovrà eseguire una serie di operazioni continue, come monitorare gli interruttori per armare il sistema e azionare il lancio, accendere e spegnere i LED quando necessario e gestire il conto alla rovescia monitorando l’interruttore range safety durante il conto. La Figura 13-12 mostra le azioni di cui si occupa il ciclo principale.
Figura 13-12 - Le operazioni del ciclo principale.
Nel punto 1 del diagramma, il ciclo comincia a leggere gli interruttori rotativi (select dell’accenditore e select dell’ora del conto). Se l’ora del conto è cambiata rispetto all’ultima volta in cui è stato letto l’interruttore e il conto è attivo (cioè, si sta preparando un lancio), il lanciarazzi interromperà il conto, disarmerà il sistema ed entrerà nello stato “abort”. Nel punto 2, il software controlla l’interruttore che arma il lanciarazzi. Se nell’iterazione precedente del ciclo era spento, ma adesso è acceso, viene impostato il flag arm del sistema e viene attivato il relè che alimenta il lancio (vedere Figura 13-9). Se questo flag è true, controlliamo se è in corso un conto. In caso affermativo, non leggiamo l’interruttore di avvio del lancio (punto 3). Altrimenti, controlliamo se l’utente ha premuto il pulsante di lancio. Se è così, impostiamo lo stato del lancio su true (on) e facciamo partire il contro. Quello che è contenuto nel lato destro della Figura 13-12 è attivo soltanto se il sistema si trova nello stato di lancio ed è in corso un conto. Nel punto 4, avviene un controllo per
verificare che l’interruttore range safety non sia premuto (on). Se no, interrompiamo il sistema e lo passiamo nella modalità di sicurezza. Il punto 5 è dove avviene l’azione vera e propria. Quando il conto arriva a zero, vengono attivati i relè del lancio che corrispondono ai circuiti di accensione selezionati. I relè sono mantenuti in uno stato on per 2 secondi e poi rilasciati. Probabilmente questo non è il modo migliore di fare questo. Sarebbe meglio controllare lo stato degli accenditori e disattivare i relè una volta che sono aperti tutti gli accenditori. Il ritardo di tempo sarebbe un tempo massimo permesso prima di dichiarare un guasto. Nel punto 6, il lancio è avvenuto correttamente oppure il razzo è ancora (si spera) al suo posto. In ogni caso, il sistema viene riportato in uno stato di standby, i relè vengono spenti e il relè principale viene disattivato. Vi suggerirei anche di disarmare il sistema, in modo che l’utente possa disattivare l’interruttore e riattivarlo di nuovo per tornare ad armare il lanciarazzi. La lettura degli input degli interruttori, l’impostazione degli stati dei LED, la lettura dell’RTC e il controllo dei relè possono avvenire molto rapidamente. In questo design, non sembra che siano necessari interrupt. Detto questo, potete decidere di aggiungerne uno per l’interruttore range safety. Ecco perché è stato collegato direttamente alla Mega2560 anziché per mezzo dell’expander I/O. L’interruttore range safety può essere utilizzato per azionare un interrupt che disattivi il relè di alimentazione degli accenditori (relè 3, modulo relè 2) nel momento in cui viene rilasciato l’interruttore. Quindi, anche se la MCU impiega poche decine di millisecondi a leggere lo stato dell’interruttore e risponde passando il sistema in uno stato di blocco, agli accenditori dei motori dei razzi l’alimentazione sarà già stata tagliata. L’LCD può essere utilizzato per mostrare messaggi durante il ciclo. Sarebbe ideale vedere lo stato della corrente e ricevere dei messaggi se si produce un guasto. Non sarebbe particolarmente utile ripetere l’ora o il conto con l’LCD. Questo non farebbe che aggiungere latenza (cioè, un ritardo nell’esecuzione) nel ciclo principale. Quando scriviamo il software, la nostra guida principale devono essere i requisiti funzionali. Queste sono cose che il software deve supportare per poter soddisfare i requisiti e di conseguenza raggiungere gli obiettivi del progetto. Se volete vedere degli esempi di modi per organizzare il software in moduli, potete rileggere i Capitoli 10, 11 e 12. Nella Figura 13-12, possiamo vedere che ci sono diverse possibilità per ulteriori moduli. Lo stato e l’aggiornamento degli accenditori è una, così come l’aggiornamento della visualizzazione dell’RTC e dell’ora. La sezione del ciclo dedicata al lancio (tutto quello che è compreso tra il punto 4 e il punto 6) è un altro possibile candidato per un modulo a sé stante. Il modulo RTC, l’LCD, i display LED e l’expander I/O molto probabilmente avranno classi definite, ma per le funzioni del ciclo principale può non essere particolarmente necessario utilizzare classi. Non sono complesse, davvero Dal momento che questa è un’analisi del design e non un design completo, lascerò il software qui. Se volete proseguire e creare il vostro lanciarazzi, vi consiglio di guardare
gli esempi forniti dai tre capitoli precedenti. Con questa analisi del design come punto di partenza, non dovreste avere molte difficoltà a lavorare sui dettagli rimanenti. Non possiamo realmente definire una stima dei tempi perché non abbiamo modo di sapere chi scriverà il software. Persone diverse lavorano a ritmi diversi: quello che per una persona richiede un’ora per essere scritto in forma di codice, per un’altra persona può richiedere mezza giornata. Quindi, per farvi un’idea di quanta fatica può richiedere il software, vi consiglio di provare a scrivere un po’ di codice di prova con una breadboard o un prototipo non dedicato (come abbiamo visto nei capitoli precedenti) per fare qualcosa con l’RTC o l’LCD. Una volta che vi siete fatti un’idea generale di quanto tempo richiede, potete moltiplicarlo per il numero di funzioni uniche contenute nel design del software e poi moltiplicare quel numero per due. Il risultato dovrebbe avvicinarsi alla quantità di tempo del quale avrete bisogno e, se riuscite a completare il software prima, tanto meglio.
I test e il funzionamento Una pianificazione dei test è sempre una buona idea. Fortunatamente, il lanciarazzi è relativamente facile da testare, dal momento che fondamentalmente è soltanto input di interruttori e output di relè. Potete simulare la continuità degli accenditori semplicemente collegando un jumper tra le coppie di morsetti degli output degli accenditori e un circuito aperto è semplicemente la mancanza di un jumper. Se esaminate i requisiti funzionali, potete vedere che sono tutti verificabili. In altre parole, se ruotate la manopola di selezione dei circuiti degli accenditori dovete vedere i LED attivi accendersi in sequenza dall’1 al 6. Se i morsetti sono collegati per simulare gli accenditori, deve essere accesa anche la luce “ICC GO”. Armate il sistema e poi premete e tenere premuto l’interruttore range safety e vedrete accendersi la luce “Safety GO”. Se avviate il conto e poi scollegate uno qualsiasi degli accenditori attivi, cambiate il numero dei circuiti degli accenditori oppure la durata del conto quando è in corso, oppure se rilasciate l’interruttore range safety, il sistema deve fermare il conto ed entrare nello stato di blocco. Fate attenzione a non lasciare che il conto arrivi a zero, se state utilizzando jumper sui morsetti per simulare gli accenditori. Quando i relè si chiudono, tutta la corrente della batteria scorrerà attraverso i jumper. Questo può far sciogliere i ponticelli o danneggiare i relè, oppure entrambe le cose. Un miglior approccio per eseguire i test può essere utilizzare fusibili che si possono sostituire o addirittura accenditori veri e propri montati su una base di legno. Potete ance riuscire a utilizzare piccole lampadine a incandescenza con una tensione corretta, ammesso che siano dotate di una resistenza bassa fredda (non illuminate). Un tipico accenditore è circa 0,5 ohm.
Analisi dei costi Il costo finale del lanciarazzi dipende da dove acquistate le parti e se riuscite a trovare
offerte. Uno dei costi principali è rappresentato dallo chassis, che può arrivare a 30 $. Potete decidere di costruire uno chassis di legno che misura 1 per 1 pollice (2,5 per 2,5 cm) e un truciolato di 1/4 di pollice (0,6 cm), ma questo immaginando che disponiate degli strumenti di falegnameria necessari. Dopo aver acquistato i materiali e averli aggiunti nel calcolo del tempo, potete scoprire che risultava più economico comprare uno chassis. Basandoci sull’elenco finale delle parti mostrato nella Tabella 13-5, il costo totale della versione Fase I probabilmente si aggirerà sui 125 $, 25 $ più 25 $ meno. Le funzionalità della Fase II possono facilmente far salire il costo fino a 300 $, ma probabilmente potete riuscire a contenerlo acquistando in modo astuto e cercando offerte.
