progettazione e sviluppo prototipale di un sistema

UNIVERSITÀ DEGLI STUDI DI ROMA
“TOR VERGATA”
FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA SPECIALISTICA
IN
INGEGNERIA MEDICA
PROGETTAZIONE E SVILUPPO PROTOTIPALE
DI UN SISTEMA DOMOTICO UNIVERSALE DI
MONITORAGGIO E CONTROLLO PER UTENTI
DISABILI
Relatore
Prof. Nicola Rosato
Candidato
Alessandro Rizzo
Correlatori
Ing. Paolo Abundo
Ing. Stefano Gelli
Matr. 0098920
ANNO ACCADEMICO 2007/2008
A mia nonna Antonietta
e a Valentina.
Indice
RIASSUNTO
INTRODUZIONE – UN NUOVO MODO DI INTENDERE L’AUSILIO
I
IV
1
I SEZIONE - IL PROGETTO
Le specifiche progettuali
1. PROGRAMMABLE INTERFACE CONTROLLER
7
10
1.1. I Microcontroller
10
1.2. I PIC
12
1.3. PIC16F628
14
1.4. Organizzazione della memori
16
1.4.1. STATUS register
17
1.4.2. OPTION register
19
1.4.3. INTCON, PIE1, PIR1 registers
20
1.4.4. PROGRAM COUNTER e STACK register
23
1.5. Le porte di I/O
23
1.5.1. PORTA e TRISA
23
1.5.2. PORTB e TRISB
26
1.6. Il modulo USART
30
1.6.1. Il Baud Rate Generator
32
1.6.2. Configurazione e registri
34
1.7. Risorse di interrupt
2. LO STRATO FIRMWARE
39
41
2.1. Introduzione all’Integrated Development Environment
41
2.2. Il Firmware
45
2.3. Il Programmatore
54
3. I PROTOCOLLI DI COMUNICAZIONE
55
3.1. Le scelte progettuali
55
3.2. EIA RS-232
57
3.3. Il protocollo Wi-Fi
67
I
3.4. Il convertitore RS-232 Wi-Fi, l’EZL80c
4. IL CIRCUITO DI CONTROLLO
69
81
4.1. Perché un device RS-232
84
4.2. Il circuito di connessione RS-232
84
4.3. Lo stadio di pilotaggio del carico
94
4.4. Lo stadio di alimentazione
99
4.5. Il pin RB5
103
4.6. Passareal Wireless
104
5. L’INTERFACCIA UTENTE IN VISUAL BASIC
109
5.1. Obiettivi dell’interfaccia
110
5.2. VB6, programmazione basata sugli eventi
110
5.3. B-SERIAL, l’interfaccia utente
112
5.3.1. MSCOMM
115
5.3.2. WINSOCK
119
II SEZIONE – L’APPLICAZIONE
Il lato attuatore
125
6. DOMOTICA, LO STATO DELL’ARTE
127
6.1. Demotica
127
6.1.1. Dispositivi d’uscita
140
6.1.2. Sistemi di controllo e gestione
141
6.1.3. Dispositivi di sistema
142
6.1.4. Interfacce e residential gateway
142
6.2. Il mercato
144
6.2.1. Il sistema KONNEX
145
6.2.2. Il sistema LONMARK
147
6.2.3. BTicino
149
7. UNA POSSIBILIE APPLICAZIONE
152
II
7.1. Caratterizzazioni
152
7.2. L’applicativo
154
7.3. Il circuito di feedback
159
8. FASE DI COLLAUDO
173
8.1. Assemblare il sistema
173
8.2. I componenti
174
8.2.1. L’interfaccia
174
8.2.2. Il circuito di controllo
179
8.2.3. Il modulo di conversione EZL
179
8.2.4. L’attuatore
180
8.2.5. Lo stadio feedback
181
8.3. L’assemblaggio
181
CONCLUSIONI
182
BIBLIOGRAFIA
189
RINGRAZIAMENTI
III
RIASSUNTO
Il seguente lavoro è stato realizzato con la partecipazione della B-Able s.r.l., azienda
nata con l’intento di sviluppare nuove soluzioni ad elevato contenuto tecnologico,
nell’ambito dell’Assistive Technology per l’integrazione dei disabili. Proprio in
quest’ottica, quello che si andrà a descrivere è un sistema domotico pensato in modo
specifico per utenti diversamente abili che presenti caratteristiche di facile installabilità.
L’obiettivo è la realizzazione di un sistema basato su una piattaforma universale,
personalizzabile da un lato alle disabilità del soggetto e dall’altro ai diversi tipi di
attuatori domotici controllati, che andranno a costituire il nostro sistema di ausilio. A
questo scopo è stato improntato un circuito di controllo basato fondamentalmente su un
microcontrollore della Microchip, il PIC16F628, che grazie ad un firmware, redatto
appositamente e trasferito nella Program Memory, svolge le funzionalità richieste. In
particolare, il microcontrollore gestisce una comunicazione bidirezionale su wireless
LAN (Wi-Fi) con l’interfaccia utente realizzata, controlla l’attuatore e riceve un segnale
destinato all’utente da uno stadio di feedback, appositamente realizzato, al fine di
rendere cosciente lo stesso dello stato dell’attuatore controllato. Ed è proprio al fine di
permettere all’utente di controllare il sistema e di riceverne opportuno ritorno,
sfruttando le proprie abilità residue, che è stato realizzato un software di interfaccia in
Visual Basic che, insieme al personal computer utilizzato, è in grado di costituire per
l’utente una Stazione di Controllo a comando vocale (implementato tramite apposito
software). Per testare le funzionalità e le prestazioni del sistema realizzato se ne è
proposta un’applicazione specifica, dedicata al controllo cosciente dell’illuminazione
ambientale, destinata a persone con estrema limitazione nei movimenti (allettate) o con
disabilità visiva di vario grado. È stato quindi necessario realizzare uno stadio di
feedback dedicato, basato su fotorilevatore capace di discriminare in modo efficiente il
livello di luminosità presente, per poterlo poi comunicare allo stadio di controllo. Al
termine del lavoro siamo dunque giunti alla realizzazione completa di un sistema,
seppur in uno stadio ancora prototipale, che può permettere all’utente di ottenere il
controllo domotico completo dell’abitazione (luci, azionamento di porte, finestre,
serrande, etc.), ricevendo inoltre informazioni di ritorno dimensionate sulle sue abilità
residue.
IV
INTRODUZIONE
Un nuovo modo di intendere l’ausilio
Dal momento in cui furono introdotte in Italia le “nuove tecnologie” come ausilio per
l’handicap, sono passati ormai più di quindici anni. Anche per merito della disponibilità
delle nuove soluzioni tecnologiche, da una cultura riabilitativa di taglio
prevalentemente ortopedico-sanitario, si è passati oggi, ad una maggiore attenzione alle
potenzialità e ai bisogni di autonomia del disabile nella comunicazione e
nell’interazione con l’ambiente, nell’ambito di processi di apprendimento, di vita
quotidiana, di lavoro e di integrazione sociale. Questa nuova impostazione segue le
politiche sviluppate negli ultimi anni dalla stessa UE in tema di disabilità e di
inclusione sociale, che vedono come fine ultimo proprio la realizzazione di una società
inclusiva, basata sulla presa di coscienza che, l’integrazione delle persone disabili non
riguarda più solo il loro empowerment, ma rappresenta una sfida per l’intera società in
tutti i contesti di vita.
Lo
sviluppo
dell’informatica
e
della
microelettronica
ha
reso
disponibili
apparecchiature che facilitano lo svolgimento di funzioni complesse, semplificando
anche drasticamente l’effettuazione dell’atto motorio. In molti casi gli ausili
tecnologici possono essere proposti come mediatori funzionali anche in età molto
1
precoce: fin dalla scuola materna le tecnologie possono aiutare il bambino disabile a
condurre esperienze dirette di gioco e di interazione con l’ambiente, compensando,
almeno in parte, le difficoltà motorie.
L’immagine del ”bambino disabile al computer” che è ormai familiare, in un
osservatore inesperto può generare l’ingannevole impressione, che il potente ausilio sia
la soluzione che compensa la disabilità, pareggiando in qualche modo la disparità
esistente con gli altri bambini. Se in ambito educativo e riabilitativo non mancano
certo i successi legati all’uso degli ausili tecnologici, l’esperienza condotta sul campo
induce ad un realistico ridimensionamento, o meglio, ad un ricollocamento delle
aspettative legate al potere “risolutivo” dell’ausilio. Nell’attuale situazione di
evoluzione tecnologica, si registra un fortissimo incremento di interesse verso gli ausili
tecnologici che vanno però visti sotto una nuova luce proveniente dalle esperienze
maturate dai professionisti del campo. Per esempio, nel caso delle patologie motorie e
sensoriali, l’esistenza di una estesissima gamma di menomazioni e disabilità funzionali
ci obbliga a tenere presente che:
a) non è quasi mai possibile rifarsi a processi comuni e ripetibili, a partire dalla
conoscenza della sola diagnosi, per capire quali ausili proporre in una certa situazione
di handicap. Solo in rari casi infatti è possibile stabilire a priori un legame preciso fra
menomazione - disabilità – handicap : una stessa menomazione (es. una
malformazione scheletrica dovuta a paralisi cerebrale infantile) può dare luogo a
disabilità diverse in persone diverse, per non parlare della frequente presenza di più
disabilità sovrapposte; la stessa disabilità può inoltre dare luogo a diverse situazioni di
svantaggio esistenziale, a seconda dei diversi contesti di vita della persona. Persone
con uguale menomazione possono svolgere lo stesso compito con strumenti del tutto
diversi, così come il medesimo strumento (es. informatico) può servire per svolgere
funzioni differenti.
b) Non vale l’equazione: persona disabile + ausilio tecnologico = persona normale.
Questa affermazione, apparentemente scontata, svela il non confessato desiderio di
investire l’ausilio di un ruolo risolutore di situazioni complesse. In realtà questa
semplificazione può portare a situazioni veramente problematiche, evidenti soprattutto
in ambiente scolastico o lavorativo: fronte di una esigenza di produttività, l’ausilio può
2
essere investito del ruolo di "normalizzatore", senza coinvolgere cambiamenti od
adattamenti delle condizioni di soggetto ed ambiente. Il processo di integrazione
richiede viceversa un contributo attivo nell’adattamento reciproco persona-ambiente;
proporzionalmente alla gravità del caso, le oggettive situazioni di difficoltà impongono
profondità ed esaustività di analisi e non è pensabile un approccio che sposti l’onere
dell’adattamento solo su uno dei due elementi, né tantomeno sull’ausilio mediatore.
c) È rischioso parlare di “ausili per il conseguimento dell’autonomia ” tout-court: il
superamento di un impaccio o di una invalidità motoria non significa necessariamente
essere autonomi, nè è sempre vero il viceversa: l’autonomia non va confusa con
l’indipendenza o l’auto-sufficienza. Si preferisce relativizzare l’obbiettivo di
autonomia parlando di ”autonomia possibile”, concetto del tutto relativo alla specifica
persona e alla particolare situazione.
d) Non si può dire se un ausilio sia più o meno valido in assoluto. Nel campo delle
nuove tecnologie la validità di un ausilio spesso viene confusa con il livello di
sofisticazione tecnologica: ausili poveri, cioè non o poco tecnologici, possono invece
risultare
molto
più
funzionali
e
immediati
di
soluzioni
tecnologicamente
avveniristiche, o meglio si possono utilizzare ausili diversi a seconda delle situazioni.
Sfruttando il supporto di un centro specializzato e con le giuste competenze, si possono
escogitare soluzioni ottimali utilizzando quei “mattoni” tecnologici già presenti sul
mercato, riadattandoli e ricombinandoli però allo scopo di ottenere soluzioni
customizzate ed innovative, come ci si è riproposto di fare proprio nel presente lavoro.
L’ausilio è, in realtà, un sistema formato da diversi apparati: è ben noto, ad esempio,
che un PC è grossolanamente schematizzabile in una o più periferiche di input, una
unità di elaborazione (hardware e software) e una o più periferiche di output. Facciamo
nostra questa nota schematizzazione per applicarla all’ausilio tecnologico che, sia in
caso di disabilità motoria che sensoriale, dovrà presentare particolare cura per quanto
riguarda l’aspetto degli accessi alla macchina (cioè dei sistemi di input alternativi
facilitati) e gli output. La persona disabile si rapporta con l'ambiente mediante una serie
di azioni svolte con "modalità" non sempre comprensibili od efficaci: il compito
dell'ausilio è aumentare l'efficacia di queste azioni, se necessario compiendo una
3
elaborazione o una vera e propria opera di "traduzione" di codici espressivi e
funzionali. Per questo motivo durante la fase di progettazione, più che di ausilio puro e
semplice, é opportuno pensare ad un “sistema ausilio”, come ad un insieme più o meno
complesso di apparati hardware e/o software, che riceve segnali particolari dalla persona
disabile e li ritrasmette in modo più comprensibile od efficace, sia all'ambiente
circostante che al soggetto diversamente abile. Per quanto riguarda la ritrasmissione,
bisognerà prestare particolare attenzione alle capacità e alle abilità residue del soggetto,
che detteranno le modalità con le quali il dispositivo genererà un opportuno feedback,
legato all’attività svolta dall’utente stesso o allo stato del sistema con il quale il soggetto
vuole interagire. Proprio grazie a questo tipo di approccio, è sorta la necessità di
realizzare un sistema ausilio che presentasse, nelle specifiche di progetto, la capacità di
realizzare uno switching sensoriale per garantire all’utilizzatore piena conoscenza
dell’attività svolta; parleremo di questo aspetto centrale più avanti nel corso del lavoro.
Torniamo alla definizione di ausilio che, come l’esperienza comune ci insegna, viene
spesso sbrigativamente identificato solo con l’elemento più “potente” dell’intero
sistema (è tipico il caso dell’elemento computer, ritenuto il nucleo realmente importante
del sistema ausilio al punto da sottovalutare gli altri elementi). Lo schema che segue
può aiutare a fare chiarezza in relazione alla natura composita dell’ausilio; sistema
composito, in cui i componenti hanno diversi ruoli, ma tutti di uguale importanza.
L’accesso personalizzato (ad es. un particolare sensore) è tanto importante quanto l’
attuatore (costituito ad es. dalla componentistica dotata di intelligenza), e quest’ultimo
non risolve alcun problema se non è corredato di opportuno software (elaborazione) e se
non fornisce un output nelle modalità adeguate. Nel seguito si chiarirà meglio il
significato dei diversi “blocchi” illustrati.
4
Figura 1- Il sistema Ausilio. Schema di principio
Qualche esempio relativo a casi concreti può aiutare a capire meglio; il caso più
semplice è quello in cui l'ausilio si può ridurre ad un solo accesso personalizzato: ad
esempio l'accensione della luce può essere possibile se l'interruttore è personalizzato,
l'uso del computer può diventare possibile grazie ad adattamenti della normale tastiera,
etc. In casi di maggiori difficoltà motorie e sensoriali combinate, la particolare
differente abilità rende necessaria una mediazione più importante dell'ausilio: ad
esempio nel caso di un soggetto che è in grado di controllare una sola funzione
elementare (ad esempio un solo movimento di un’unica parte del corpo) e desidera
effettuare funzioni complesse (es. scrivere, controllare l’ambiente, ... ), l'ausilio deve
essere uno strumento intelligente, con una interfaccia in grado di elaborare un codice
elementare (ad esempio un azionamento di un sensore) in un segnale che possa
governare l’ attuatore (computer) per produrre output quali la scrittura, il controllo
dell’ambiente, etc. In più, un’altra fondamentale osservazione proviene da quanto
accennato in precedenza: l'interazione illustrata evidenzia il ruolo dell’ausilio come
mediatore nel percorso che va dalla persona disabile verso l'ambiente; inferiormente
(tratteggiato) sono indicate le interazioni in senso opposto, cioè gli effetti che la
presenza dell’ausilio produce verso la persona disabile. Come si potrebbe infatti,
interagire con un qualsiasi oggetto, senza averne un qualche tipo di ritorno che ci possa
fornire coscienza del nostro operato? Basta pensare ad una semplice attività di tutti i
5
giorni come quella di scrivere una mail. Saremmo forse in grado di effettuare tale
operazione se non disponessimo dello schermo del PC che fornisce traccia del nostro
scritto, o del feedback tattile fornito dalla tastiera con la quale scriviamo? Ecco perché il
nostro ausilio dovrà (il device descritto e realizzato nel lavoro segue questa specifica)
fornire, in ritorno, un’informazione recepibile dall’utente diversamente abile e che possa
servire allo stesso per prendere coscienza dell’attività svolta. Proviamo a classificare
queste interazioni di ritorno, che potranno essere:
-
l'informazione di ritorno fornita dall’ausilio stesso alla persona durante l’uso,
definita, come già detto, “retroazione” o “feedback”: ne sono un esempio il
contenuto dello schermo del computer che varia a seconda dei comandi
impartiti, o nel caso di un sensore, il semplice “click” che segnala l’avvenuto
azionamento;
-
l'azione dell'ambiente verso la persona, aspetto nel quale l'ausilio deve giocare
un ruolo di mediatore, se l’utente non possiede le capacità necessarie a captare i
cambiamenti provenienti dall’ambiente a seguito delle sue azioni.
All’interno di questo panorama, composto da nuove concezioni e nuove possibilità
tecnologiche, si inserisce il progetto che stiamo per vedere descritto. L’idea
fondamentale comprende la progettazione e la realizzazione di un device, capace di
sfruttare le abilità residue dell’utente, per interagire con attuatori di tipo domotico. Il
dispositivo dovrà essere concepito in modo tale da poter inoltre fornire all’utente un
valido ed effettivo feedback legato all’azione proveniente da lui steso. Per essere
definita valida, la retroazione dovrà essere generata tenendo in considerazione le
capacità dell’utente disabile, garantendo quello shifting sensoriale che gli permetterà di
prendere coscienza delle azioni eseguite. Il passo successivo sarà quello di comporre
una vera e propria power-station, che possa consentire il controllo effettivo degli
applicativi domotici usati nella vita quotidiana.
L’ausilio potrà in questo modo aumentare le possibilità dell’utente finale, amplificando
la sua volontà e contribuendo ad incrementare la sua libertà.
6
I SEZIONE – IL PROGETTO
Le specifiche progettuali
In questa fase ci proponiamo di delineare e stabilire i requisiti e le specifiche relative al
sistema di ausilio che abbiamo intenzione di progettare. Nella fattispecie, mediante
l’analisi e l’elaborazione delle suddette specifiche, implementeremo il progetto delle
diverse componenti del nostro sistema e produrremo quindi il prototipo associato.
È opportuno preliminarmente, soffermarsi sulle specifiche di progetto, provenienti
dall’analisi dei vincoli che nascono dallo studio della problematica che ci si propone di
affrontare.
L’idea di partenza, come abbiamo accennato nell’introduzione, è quella di realizzare un
dispositivo di controllo domotico, che permetta ad un utente disabile di comandare
applicativi di uso quotidiano (come il controllo della luminosità domestica, l’apertura di
porte, serrande automatizzate, elettroserrature, ecc.) e di poter ricevere un effettivo
segnale di ritorno misurato alle sue capacità sensoriali e motorie residue. L’obbiettivo
dell’ausilio deve quindi essere quello di fornire al soggetto sia i mezzi per interagire con
l’ambiente esterno, che di ricevere in maniera autonoma informazioni sul risultato
prodotto dal sistema stesso.
7
In primis, è di interesse capire la componente di controllo più adatta da utilizzare: per
far ciò è necessario analizzare i cosiddetti microcontrollori; è proprio il microcontrollore
(come descriveremo dettagliatamente in seguito, noi abbiamo scelto il PIC16F628
prodotto dalla Microchip), programmato in modo specifico tramite un firmware
apposito, che svolge l’attività di controllo sull’attuatore e di monitoraggio dell’attività
svolta, realizzando quel collegamento bidirezionale tra macchina e utente disabile che
costituisce senza dubbio una delle componenti innovative del progetto.
Complessivamente, il sistema di ausilio deve quindi:
-
intercettare in qualche modo i comandi imposti dalla persona;
-
azionare un determinato applicativo;
-
verificare che l’azione abbia portato al risultato desiderato;
-
portarne infine traccia all’utente in un modo che sia da lui comprensibile, in base
alle proprie capacità motorie/sensoriali residue.
Per massimizzare il grado di adattabilità del nostro dispositivo, sia per quanto riguarda
le condizioni di disabilità che possono variare da soggetto a soggetto, sia per quello che
concerne l’evidente eterogeneità di attuatori da dover controllare, l’obiettivo è quello di
mettere insieme uno stadio di controllo che si collochi in posizione intermedia tra
l’utente finale e lo strato applicativo. Questo garantirebbe universalità al nostro sistema
(da noi voluta), rendendone possibile la customerizzazione più opportuna a seconda
delle necessità.
Preso atto di tali esigenze, si è deciso di garantire tale “posizione intermedia”, tramite il
collegamento del device di controllo con un normale personal computer, l’host del
nostro sistema, che provvederà tramite impostazioni opportune e programmi di
interfaccia ad hoc (a questo proposito consultare il capitolo dedicato presente in questa
stessa sezione), pensati per fornire all’utente quell’interfaccia dedicata e customizzata
sulle sue possibilità (il pc sarà fornito di touch screen per supplire ad un’eventuale
deficienza motoria o di controllo vocale nel caso di disabilità visiva, ecc.). Il
microprocessore e l’hardware appositamente realizzato, da parte sua, si occuperà perciò
di recepire i segnali inviatigli dall’host, tradurli in comandi verso l’applicativo
(svolgendo tipicamente un’attività di controllo a livello dell’alimentazione), e ricevere
grazie a sensori (uno stadio a fotodiodo nel caso di controllo dell’illuminazione, contatti
o fotocellule per azionamenti di porte e finestre, ecc.), un segnale che possa poi tornare
8
indietro fino all’host, che comunicherà all’utente che la sua azione è andata a buon fine,
tramite mezzi comunicativi scelti in base alle capacità residue dello stesso.
In questo modo si garantisce l’opportuna universalità, che contribuisce senza dubbio ad
abbassare i costi. Quest’ultima osservazione deriva direttamente dalla esigenza di far
essere a basso costo la realizzazione del progetto. Ciò è strettamente legato all’idea di
realizzare un prodotto funzionante, che soddisfi le specifiche e che presenti in aggiunta
un costo limitato. Per garantire quest’ultimo aspetto, si è concepito un device in grado
di ridurre al minimo le difficoltà di installazione e di collegamento al possibile attuatore
(plug and play) e composto da parti reperibili facilmente sul mercato a prezzi
decisamente accessibili. Nei capitoli successivi verranno descritte le caratteristiche
dell’hardware realizzato: per ora anticipiamo che il sistema di controllo viene collegato
direttamente all’alimentazione del dispositivo che deve controllare, prevedendone in
questo modo una modificazione minima.
Riassumendo, col seguente lavoro, ci si propone di realizzare un sistema di ausilio che
preveda al suo interno una parte di controllo fondamentale, basata sulla logica
programmabile di un microcontrollore, che presenti forti caratteristiche low-cost e di
semplicità e robustezza di installazione, e garantisca inoltre le suddette funzioni di
controllo e monitoraggio per un utente diversamente abile.
Vediamo a questo punto da vicino, quali sono i componenti principali e come si è
proceduto alla progettazione e realizzazione prototipale delle singole parti del sistema,
tenendo sempre conto delle specifiche imposte. Cominciamo col core dello stesso,
ovvero il microcontrollore.
9
1. PROGRAMMABLE INTERFACE CONTROLLER
1.1 I Microcontroller
Per la realizzazione della componente dotata di intelligenza, indispensabile per la
realizzazione di un’interfaccia in grado di sfruttare e interpretare le abilità dell’utente e
capace di fornire al contempo un adeguato feedback, è stato scelto un integrato prodotto
dalla Microchip® appartenente alla classe dei PICmicro®.
Il PIC rientra nella famiglia dei microcontroller, vediamo quindi, innanzi tutto, da cosa
sono caratterizzati i componenti elettronici così definiti.
Un microcontrollore o microcontroller, detto anche computer single chip è un sistema
a microprocessore completo, integrato in un solo chip, progettato per ottenere la
massima autosufficienza funzionale ed ottimizzare il rapporto prezzo-prestazioni per
una specifica applicazione, a differenza, ad esempio, dei microprocessori impiegati nei
personal computer, adatti per un uso più generale.
10
Fig.1.1 – I microcontrollori hanno dimensioni ridottissime
I microcontroller sono la forma più diffusa e più ridotta di computer: essi sono costituiti
da una CPU, da un certo quantitativo di memoria RAM e memoria ROM (che può
essere PROM, EPROM, EEPROM o FlashROM) e da una serie di interfacce di I/O
(input/output) standard, fra cui molto spesso bus (I²C,SPI,CAN,LIN). Le periferiche
integrate sono la vera forza di questi dispositivi: si possono avere convertitori ADC e
convertitori DAC multicanale, timer/counters, USART (come nel PIC utilizzato nel
presente lavoro ), numerose porte esterne bidirezionali bufferizzate, comparatori, PWM.
Tali dispositivi sono contenuti in numerosi apparecchi ed elettrodomestici, come ad
esempio, videoregistratori e i televisori costruiti dopo il 1990, nelle macchine
fotografiche e nelle videocamere, nei lettori CD e DVD, nei controlli automatici di
macchine industriali, in molte lavatrici e frigoriferi di ultima generazione, nelle
centraline di controllo delle motociclette e delle automobili (in una sola automobile
possono essere presenti anche molte decine di microcontrollers), negli antifurto
elettronici, nei registratori di cassa dei negozi, nelle centraline dei semafori, etc. La loro
capacità di calcolo è molto limitata, a dispetto della velocità ragguardevole che possono
raggiungere e di solito eseguono lo stesso programma ( firmware ) per tutta la durata del
loro funzionamento.
I microcontroller sono progettati e realizzati per fornire una risposta real-time agli
eventi da essi controllati. A questo scopo, quando un determinato evento si presenta, un
Interrupt di sistema può segnalare al controllore di sospendere il processamento delle
istruzioni correnti e di iniziare una cosiddetta interrupt service routine (ISR, presente
nello stesso firmware illustrato nella sezione seguente). L’ISR contiene le istruzioni che
serviranno al microcontrollore per il processing dell’interrupt, prima che questo possa
ritornare alla sequenza originale del codice costituente il firmware. L’interrupt può
essere prodotto da diversi eventi device-dependent come un overflow di un timer
11
interno al chip, il cambiamento di un bit di I/O, la ricezione di un messaggio seriale (il
nostro device utilizzerà proprio un interrupt di questo tipo per svolgere la sua funzione)
e in generale il verificarsi di un certo evento proveniente dalle periferiche collegate al
microprocessore stesso.
Il programma o firmware di cui si è parlato in precedenza, deve rientrare nella program
memory disponibile sul chip, molto spesso di dimensioni ridotte. Questo provoca, come
è immediato dedurre, che il programma da caricare nel controllore debba essere molto
compatto e composto da un numero limitato di righe, non potendo perciò raggiungere
complessità troppo elevata. Per questo motivo il linguaggio di programmazione
prediletto nello sviluppo di software simili è l’assembly, che come è noto fornisce
codici compatti e di ridotte dimensioni, anche se la realizzazione di ambienti di sviluppo
dedicati (IDE) ha permesso di sviluppare in modo adeguato codice in linguaggi di più
alto livello. La program memory inoltre, a seconda del dispositivo, potrà essere del tipo
a sola lettura, permanente o riprogrammabile come nel caso dei PIC di serie F utilizzati
nel presente progetto.
Dato che i suddetti microcontrollori sono nella maggior parte dei casi usati per
controllare devices, devono essere necessariamente in grado di ricevere input dai
dispositivi controllati e di interpretarli grazie anche alla presenza di convertitori A/D
D/A che permettono al controllore di convertire i dati in ingresso in forma digitale
riconoscibile e processabile.
1.2 I PIC
Abbiamo adesso chiaro in mente cos’è un microcontrollore e possiamo senza dubbio
annoverare tra di essi i PIC essendo questi ultimi dei circuiti integrati, prodotti dalla
Microchip Technology Inc., ovvero dei componenti che racchiudono in un unico
dispositivo tutti i componenti necessari a realizzare un completo sistema digitale
programmabile. Come si vede in figura i PICmicro (in questo caso un PIC16F84A) si
presentano esternamente come dei normali circuiti integrati TTL o CMOS, ma
internamente dispongono di tutti dispositivi tipici di un sistema a microprocessore:
•
Una CPU (Central Processor Unit) ovvero una unita' centrale di elaborazione il
cui scopo e' interpretare le istruzioni di programma.
12
•
Una Program Memory, permanente o riprogrammabile a seconda del modello, in
cui sono memorizzare le istruzioni del programma da eseguire.
•
Una memoria RAM (Random Access Memory) utilizzata per memorizzare le
variabili utilizzate dal programma.
•
Una serie di LINEE DI I/O (Input/Output) ovvero linee di ingresso e uscita per
pilotare dispositivi esterni o ricevere impulsi da sensori, pulsanti, ecc.
•
Una serie di dispositivi ausiliari al funzionamento quali generatori di clock, bus,
contatori, etc.
Per quanto riguarda lo spazio dati, i PIC hanno un set di registri che funzionano come
una RAM general purpose. Nella memoria dati sono comunque mappati anche dei
registri di controllo special purpose, indispensabili per implementare tutte le
funzionalità del microcontrollore. L’estensione della memoria dipenderà dal modello
scelto, ma tutte le serie di PIC possiedono un sistema di banchi per estendere la
memoria. Tutte le serie di PIC sono realizzati secondo architettura Harvard, perciò lo
spazio di memoria dedicato alle istruzioni è separato da quello dedicato ai dati. A
seconda della famiglia e della classe di device scelto, la memoria dedicata al codice
componente il firmware è implementato tramite EPROM, ROM o memoria FLASH.
Proprio un PIC fornito di memoria di tipo FLASH (PIC della serie F) è stato scelto per
la realizzazione del presente progetto fornendo la possibilità di riscrivere più volte il
codice all’interno del microcontrollore, caratteristica fornita da memorie a sola lettura o
di tipo EPROM che necessitano di ultravioletti per cancellare la code memory,
complicando quindi un eventuale stadio di progettazione come nel nostro caso.
Tutti i PIC sono in grado di gestire dati e indirizzi composti da 8 bit, per questo sono
considerati microcontrollori a 8 bit[4].
Per quanto riguarda invece la il numero componente l’istruction set, esso varia da 35 a
70, per i PIC di ultima generazione. L’istruction set include istruzioni utilizzate per
compiere operazioni direttamente sui registri, o indirettamente passando per il
cosiddetto registro accumulatore (w) utilizzato molto spesso come registro d’appoggio
per spostare i dati da un registro ad un altro. Alcune operazioni, come quelle che
permettono di settare o resettare particolari bit, possono essere eseguite su ogni registro,
mentre come detto le operazioni di tipo algebrico richiedono l’utilizzo del w-register.
Il core del PIC è in grado di svolgere operazioni di skip che vengono utilizzate per
implementare le istruzioni condizionali eventualmente presenti nel codice[5]. Ad
13
esempio l’istruzione “skip if bit set” (che nel linguaggio assembly equivale
all’istruzione BTFSS) può essere utilizzata per compiere un salto condizionale
all’interno del flusso del codice, così da emulare il comune ciclo “if” presente nei
linguaggi di programmazione di più alto livello. Abbiamo già detto che questi
particolari dispositivi sono divisi in molte famiglie che presenteranno funzionalità
crescenti all’aumentare della complessità strutturale e dell’hardware che li costituisce.
In particolare partendo dai modelli più semplici avremo:
•
i PIC12x, tutti chip molto piccoli con soli 8 pin e vengono utilizzati per
applicazioni molto semplici. Sono considerati degli baseline devices.
•
I PIC16x, considerati come ottimi microcontrollori general purpose a 8 bit. Il
PIC utilizzato in questo progetto e di cui si parlerà in maniera approfondita nella
sezione successiva appartiene proprio a questa classe. Sono i Mid-Rang devices.
•
PIC18x, sono componenti decisamente più grandi e complessi, disponendo di un
numero di pin che va da 28 a 40. Il linguaggio di programmazione prediletto per
questi dispositivi non è più l’assembly ma il C, i registri sono a 12 bit e più
numerosi
•
PIC24x e dsPIC, introdotti nel 2004, sono dei microcontrollori a 16 bit. I
PIC24x sono general purpose, mentre i dsPIC includono funzioni di digital
signal processing.
•
PIC32MX, sono microcontrollori a 32 bit molto più potenti delle prime famiglie
prodotte dalla microchip.
1.3 PIC16F628
Passiamo ora ad una più accurata descrizione ed analisi del componente specifico che
costituisce il vero core del device realizzato. Si tratta, come già anticipato, del
PIC16F628[6]: tale dispositivo appartiene alla famiglia dei PIC16x, ed è quindi un
microcontrollore ad 8 bit. La lettera F indica che il chip utilizza una memoria
riprogrammabile di tipo flash, e non OTP (One Time Programmable). Abbiamo già
accennato all’enorme vantaggio che una memoria riprogrammabile fornisce nella fase
progettuale e di testing.
14
Fig.1.2 – Schema della piedinatura del PIC16F628
La figura ci mostra la piedinatura del pic, che possiede 18 pin; ognuno di essi verrà
preso in esame tra poco.
Se paragonato ad una CPU costituente il core di un moderno sistema di calcolo presente
in commercio, il PIC risulta avere performance nettamente inferiori (ci troviamo davanti
un microcontrollore a 8 bit contro 32/64 bit di una cpu montata all’interno di un comune
Personal Computer!). In realtà la forza di un dispositivo di tale fattura è l’elevata
specializzazione raggiungibile. Questo è reso possibile da una serie di caratteristiche
comuni ai microprocessori definiti RISC (Reduced Instruction Set Computer), classe cui
appartengono i PICMicro, tra le quali la possibilità di eseguire solamente poche
istruzioni semplici (35 nel nostro caso) ma in tempi molto brevi. Per cominciare con una
descrizione apprfondita, il PIC utilizza un’architettura di tipo Harvard nella quale gli
accessi alla program memory e alla data memory avvengono con bus diversi, questo
permette al microcontrollore di avere lunghezza di parola diversa per i dati e per le
istruzioni: infatti il bus per i dati è a 8 bit mentre il bus per le istruzioni è a 14 bit.
Per quanto riguarda la memoria presente, il microcontrollore ne ha di tre tipi: FLASH,
RAM, EEPROM.
La memoria Flash è composta da 2048 locazioni a 14 bit ed è utilizzata come Program
Memory, cioè all’interno di queste locazioni vengono memorizzate le istruzioni che
compongono il firmware.
La RAM ha 224 locazioni a 8 bit e al suo interno vi sono i registri general purpos e
special function utilizzati per salvare le variabili di programma e per interagire con
l’hardware. L’ALU è un’unità aritmetica di tipo general purpose ed esegue operazioni
booleane e aritmetiche tra dati presenti nel registro di lavoro (W) e gli altri file registers
della data memory. Il working register W è un registro a 8 bit utilizzato dall’ ALU e
viene utilizzato come appoggio per trasferire dati agli altri registri. In fig.1.3 è illustrato
uno schema a blocchi semplificato della CPU.
15
All’interno del microcontrollore sono posizionati due tipi di data memory: una memoria
non volatile di tipo EEPROM per la memorizzazione dei dati più a lungo termine come
valori di calibrazione che non verranno persi allo spegnimento del device, e una RAM
di cui abbiamo già parlato che verrà resettata al power-down.
Fig. 1.3- Blocchi funzionali CPU del PIC.
1.4 Organizzazione della memoria
Il PIC16F628 possiede un Program Counter a 14 bit capace di indirizzare 8K x 14
locazioni di program memory. Solo i primi 2K x 14 sono fisicamente implementati
(2048 locazioni). Il RESET vector, ovvero la locazione di memoria nella quale è scritta
la prima istruzione del programma che il microcontrollore esegue all’avvio, è
indirizzata a 0000h; mentre l’Interrupt vector (la trattazione dell’interrupt verrà
affrontata più avanti in questa sezione) sta alla locazione 0004h.
La Data Memory è ripartita in 4 banchi di memoria, che contengono gli SFR’s (Special
Function Registers) e i registri general purpose. Gli SFR’s sono localizzati in
16
corrispondenza delle prime 32 locazioni di memoria di ciascun banco. I registri Special
Function sono usati dalla CPU per controllare le operazioni del device. Vengono
classificati in due blocchi principali: registri di core e registri di periferica.
A questo punto, studiamo nel dettaglio i registri Special Function principali, sui quali
agirà il nostro firmware che andrà a modificare il valore dei singoli bit, rendendo così
possibile lo svolgimento delle funzioni specifiche che caratterizzeranno il dispositivo
realizzato nel presente lavoro di tesi.
1.4.1 STATUS register
La figura ci mostra i singoli bit che fanno parte e che compongono il registro stesso.
Fig.1.4 – Status Register
Questo registro contiene i bit indicanti lo stato aritmetico dell’ALU, lo stato del RESET
e i bit utilizzati per selezionare il banco di memoria della data memory sul quale si ha
intenzione di lavorare. Come abbiamo già detto, questo è un registro di tipo Special
Function, ossia i bit che lo compongono, controllano alcune particolari funzionalità e
impostazioni del microcontrollore. Questo tipo di registro non viene di norma usato per
la sola memorizzazione di dati, ma i suoi bit devono essere settati ad hoc per il corretto
funzionamento del controllore.
Vediamo da vicino la funzione di questi bit:
17
In particolare analizziamo i bit RP0 e RP1 che vengono utilizzati per selezionare il
banco di memoria della Data Memory. Detta operazione è necessaria in un
microcontrollore di questo tipo perché, com’è stato già detto, ogni banco contiene
particolari registri a funzione speciale per modificare i quali è perciò necessario, di volta
in volta, selezionare il corretto banco lungo la scrittura del firmware agendo sul valore
dei suddetti bit.
18
1.4.2 OPTION register
L’option regiter è un bit a scrittura/lettura che contiene bit che controllano le funzioni
legate al Timer e al Watch Dog Timer, all’interrupt esterno sul pin RB0 e sulla funzione
di pull-up attivabile in corrispondenza dei pin costituenti PORTB.
Fig.1.5 – Option Register
Vediamo di seguito il nome e la funzione dei singoli bit
19
1.4.3 INTCON, PIE1, PIR1 registers
Questi tre registri, contengono i bit responsabili del controllo e dell’attivazione degli
interrupt implementati all’interno del microcontrollore. I cosiddetti flag bit vengono
settati automaticamente a 1 quando si presenta il corrispondente interrupt (che deve
essere però abilitato tramite il settaggio del corrispondente enable bit); in questo modo è
possibile associare al cambiamento del bit una particolare subroutine realizzata
all’interno del firmware.Vediamo di seguito i registri con i corrispondenti bit.
Fig.1.6 – Intcon Register
20
Fig.1.7 – PIE1 Register
21
Fig.1.8 – PIR1 Register
Nel caso specifico, all’interno del firmware scritto per il nostro progetto si troveranno
dei setting che riguardano proprio la gestione di particolari interrupt che sarranno
essenziali per guidare le risposte del microcontrollore. Quelli più importanti sono il bit
RCIE
l’USART receive interrupt enable bit che abilita l’interrupt concomitante
all’avvenuta ricezione di un messaggio su seriale, il bit PEIE Peripheral Interrupt
22
enable bit che abilita gli interrupt provenienti dalle periferiche del PIC. Per quanto
riguarda i bit di tipo flag, come abbiamo detto servono a segnalare la presenza di un
determinato interrupt, e anche nel nostro programma sfruttiamo in particolare il bit
RCIF l’USART receive interrupt flag bit, che viene settato ad 1 automaticamente
quando arriva un messaggio su seriale, potendo in questo modo discriminare l’istante in
cui si ha un segnale in ingresso gestendolo in modo opportuno.
1.4.4 PROGRAM COUNTER e STACK register
Com’è noto, il Program Counter (PC) è un registro la cui funzione è quella di
conservare l’indirizzo di memoria corrispondente all’istruzione successiva. Nel caso del
nostro PIC il Program Counter è un registro composto da 13 bit. I bit meno significativi
(low bit) provengono da un registro chiamato PCL, mentre i più significativi
compongono il registro PCLATH.
Lo Stack register è invece un particolare registro nel quale viene salvato l’indirizzo di
memoria corrispondente all’istruzione successiva ad una CALL alla quale il flusso del
programma ritorna in corrispondenza del RETURN o quando si presenta una chiamata
che segue ad un interrupt.
1.5 Le porte di I/O
Il PIC16F628 possiede 2 porte di Input/Output: PORTA e PORTB. Ognuna di queste
due porte è composta da pin, alcuni adempiono anche ad altre funzioni essendo
interconnessi alle periferiche presenti nel microcontrollore. In generale quando una
particolare periferica viene attivata, i pin corrispondenti non possono essere utilizzati
come semplici pin di I/O general purpose ma vengono automaticamente destinati alla
periferica stessa.
1.5.1 PORTA e TRISA
Il registro PORTA è essenzialmente un latch a 8 bit. Come è stato detto, alcuni pin di
questa porta sono destinati ad altre funzioni tramite multiplexing, per cui possono essere
23
utilizzati per interagire con le rispettive periferiche. Il pin RA4 per esempio, oltre a
poter funzionare da general purpose I/O è utilizzato in caso di necessità come input di
clock. Gli altri pin RA possono essere utilizzati sia da input che da output, la
“direzionalità” dei pin viene settata agendo su un altro registro denominato TRISA.
Ogni bit del registro TRISA ha una corrispondenza univoca con un pin di PORTA, in
questo modo se un particolare bit del registro TRISA viene settato ad 1, il
corrispondente pin della porta A potrà essere utilizzato esclusivamente come input per il
PIC che ne leggerà perciò il contenuto; viceversa il microprocessore considererà un pin
come output solo se il corrispondente bit del registro di TRIS è stato preventivamente
azzerato. La gestione degli ingressi e delle uscite del PIC viene perciò effettuata via
SW, permettendo al programmatore di inserire righe di codice tramite le quali si dovrà
riempire in modo opportuno i registri TRIS così da garantire che i pin si comportino
come richiesto dalle specifiche progettuali, ricordando sempre di non poter utilizzare in
generale come semplici ingressi/uscite quei pin destinati alle particolari periferiche
implementate all’interno del microcontrollore. Prendiamo ad esempio il pin RA0 e
supponiamo di volerlo impostare come input, a seguito di quanto detto dovremo mettere
a 1 il bit 0 del registro TRISA corrispondente tramite la seguente istruzione:
bsf
TRISA0 = 1
TRISA,0
(istruzione Assembly)
(istruzione C)
Per capire cosa succede a seguito della precedente istruzione riportiamo di seguito lo
schema dello stadio d'uscita estratto dal data sheet della Microchip:
Fig.1.9 – Schema dello stato di uscita del PIC16F628
24
Quello che succede è una commutazione ad 1 dello stato logico del flip-flop di tipo Dlatch indicato nel blocco con il nome TRIS latch. Per ogni linea di I/O esiste uno di
questi flip-flop e lo stato logico in cui si trova dipende strettamente dallo stato logico
del relativo bit nel registro TRIS (anzi per meglio dire ogni bit del registro TRIS e'
fisicamente implementato con un TRIS latch).
L'uscita Q del TRIS latch è collegata all'ingresso di una porta logica di tipo OR. Questo
significa che, indipendentemente dal valore presente all'altro ingresso, l'uscita della
porta OR varra' sempre 1 in quanto uno dei suoi ingressi vale 1 (si veda la tavola della
verità). In questa condizione il transistor P non conduce e mantiene la linea RA0
scollegata dal positivo d'alimentazione. Allo stesso modo l'uscita negata del TRIS latch
è collegata all'ingresso di una porta AND quindi l'uscita di questa varrà sempre 0 in
quanto uno dei suoi ingressi vale 0 (vedi tavola). In questa condizione anche il transistor
N non conduce mantenendo la linea RA0 scollegata anche dalla massa. Lo stato logico
della linea RA0 dipenderà esclusivamente dalla circuiteria esterna cui la collegheremo.
Applicando 0 o 5 volt al pin RA0, sarà possibile leggerne lo stato sfruttando la
circuiteria d'ingresso del blocco rappresentata dal TTL input buffer e dal latch
d'ingresso.
Viceversa per utilizzare RA0 come uscita dobbiamo mettere a 0 il bit corrispondente nel
registro di TRIS; vediamo qual è l’istruzione da utilizzare in questo caso:
bcf
TRISA0 = 0
TRISA,0
(istruzione Assembly)
(istruzione C)
Questo determina la commutazione a 0 dell'uscita Q del TRIS latch (ed a 1 dell'uscita Q
negata). In questo stato il valore in uscita dalle porte OR e AND dipende
esclusivamente dallo stato dell'uscita Q negata del Data Latch. Come per il TRIS latch,
anche il Data Latch dipende dallo stato di un bit in un registro, in particolare del registro
PORTA. La sua uscita negata viene inviata all'ingresso delle due porte logiche OR e
AND e quindi direttamente sulla base dei transistor P ed N.
Se mettiamo a 0 il bit 0 del registro PORTA otterremo la conduzione del transistor N
con conseguente messa a 0 della linea RA0. Se invece mettiamo a 1 il bit 0 otterremo la
25
conduzione del transistor P con conseguenza messa a +5 volt della linea RA0. In questa
condizione e' sempre possibile rileggere il valore inviato sulla linea tramite la circuiteria
d'ingresso.
Di seguito riportiamo una tabella contenete i singoli pin con le relative funzionalità
associate:
Fig.1.10 –Le funzionalità dei singoli pin del PIC16F628
Come si vede tutti i pin hanno altre funzioni associate oltre quelle di I/O general
purpose.
1.5.2 PORTB e TRISB
PORTB è una porta bidirezionale a 8 bit. Come nel caso precedente, la bidirezionalità
viene gestita tramite il registro dedicato TRISB. Il setting per decidere la direzione dei
dati attraverso il particolare pin è lo stesso: un bit messo a 1 in TRISB farà funzionare il
26
pin corrispondente da input, mentre un valore pari a 0 destinerà il pin a comportarsi da
output. Anche in questo caso i pin di PORTB, sono connessi tramite multiplexing ad
altre periferiche e in più possono essere utilizzati come risorsa di interrupt nel caso in
cui questi ultimi siano stati abilitati tramite il settaggio degli appositi registri visti in
precedenza. In aggiunta, tutti i pin di questa seconda porta possiedono un leggero PullUp che viene controllato dal bit RBPU dell’ Option Register, attivabile quando le linee
sono programmate come ingressi.
In ingresso infatti, come spiegato precedentemente, le linee vengono completamente
scollegate dal PIC in quanto sia il transitor P che il transistor N sono aperti. Lo stato
delle linee dipende quindi esclusivamente dalla circuiteria esterna. Se tale circuiteria è
di tipo a collettore aperto o più semplicemente è costituita da un semplice pulsante che,
quando premuto, collega a massa la linea di I/O, è necessario inserire una resistenza di
pull-up verso il positivo per essere sicuri che quando il pulsante è rilasciato ci sia una
condizione logica a 1 stabile sulla linea d'ingresso. La circuiteria di weak pull-up
consente di evitare l'uso di resistenze di pull-up e può essere attivata o disattivata
agendo sul bit RBPU del registro OPTION . Nella figura seguente viene riprodotto lo
schema a blocchi dello stadio d'uscita della linea RB0 estratto dal data sheet Microchip:
Fig. 1.11 - Schema a blocchi dello stadio d'uscita della linea RB0
27
La sola linea RB0 inoltre, presenta una caratteristica molto particolare. Essa, quando
viene configurata come linea di ingresso, può generare, in corrispondenza di un cambio
di stato logico, un interrupt, ovvero una interruzione immediata del programma in
esecuzione ed una chiamata ad una subroutine speciale denominata interrupt service
routine.
Altre 4 linee di questa porta (RB7:RB4) possono fornire input per un interrupt in
corrispondenza di un loro cambiamento di stato logico.
Come per le linee della porta precedente forniamo una tabella nella quale vengono
elencate e brevemente descritte le funzionalità aggiuntive di ogni linea.
Fig.1.12 –Le funzionalità delle singole linee del PIC16F628
In particolare per la realizzazione del device preso in esame nel seguente lavoro, sono
importanti due linee della PORTB: RB1 e RB2. Suddette linee infatti, una volta abilitato
l’hardware relativo, forniscono i dati in ingresso e uscita dal modulo USART, di cui ci
occuperemo tra poco, che rende possibile la comunicazione seriale del PIC.
28
Nel dettaglio la RB1/RX funziona in ricezione dei pacchetti dati su seriale, mentre la
RB2/TX è il terminale di uscita del modulo di trasmissione seriale.
Fig.1.13 – Schema a blocchi delle vie RB1 e RB2
In figura vediamo lo schema dei blocchi di uscita delle vie RB1 e RB2 utilizzate come
detto per la comunicazione su seriale.
29
1.6 Il modulo USART
L’Universal
Synchronous/Asynchronous
Receiver/Transmitter
costituisce
parte
integrante delle periferiche hardwarizzate all’interno del nostro PIC, e rappresenta senza
dubbio una delle caratteristiche che hanno condizionato in modo decisivo la scelta del
microcontrollore. Il modulo USART è un dispositivo hardware di uso generale o
dedicato, converte flussi di bit di dati da un formato parallelo a un formato seriale o
viceversa.
Praticamente ogni famiglia di microprocessori ha la sua UART/USART dedicata.
Questo modulo è solitamente parte di un circuito integrato usato per la comunicazione
seriale tra un computer ed una periferica e viceversa.
Abbiamo detto che questo dispositivo permette la conversione dal formato parallelo a
quello seriale che senza dubbio rimane il protocollo di comunicazione più vantaggioso
avendo bisogno di un solo cavo per la trasmissione delle informazioni. Ogni modulo
USART contiene uno shift register che costituisce il metodo fondamentale per la
conversione operata da questo modulo.
I segnali esterni possono presentarsi in diverse forme con diversi livelli di voltaggio
caratteristici del protocollo di comunicazione utilizzato (un esempio è la trasmissione su
via seriale RS-232 utilizzata nella nostra progettazione); la comunicazione può inoltre
essere full duplex, quando entrambi i terminali collegati comunicano allo stesso tempo,
o half duplex, se i due terminali trasmettono a tempi alternati. Per i dettagli in merito
alla comunicazione seriale rimandiamo al capitolo dedicato nel quale si descrivono le
specifiche del protocollo RS-232.
Analizziamo in breve l’algoritmo che permette all’hardware dedicato di operare la
conversione parallela/seriale. Durante la comunicazione, ogni bit che compone il
pacchetto, corrispondente peraltro ad una pulsazione del livello di voltaggio, può
trovarsi solamente in uno di due stati: low o high. Solitamente lo stato logico “1”, cioè
la condizione high voltage corrisponde al mark state mentre lo stato logico “0” viene
associato allo space state. Il bit di start è normalmente sempre uno 0, e segnala al
terminale ricevente (DTE) che ci sono dei dati in arrivo. I seguenti cinque o otto bit (a
seconda del protocollo utilizzato) rappresentano il contenuto informativo vero e proprio.
L’ottavo o il nono bit possono implementare il controllo di parità necessario per una
30
verifica della correttezza durante la trasmissione. Per ultimo viene il cosiddetto stop bit
che è di tipo space e che segnala al ricevitore la fine del pacchetto trasmesso.
Tutte le operazioni effettuate dal modulo USART sono controllate da un segnale di
clock interno che ha una frequenza multipla (x16) del data rate, perciò ogni bit ha una
durata di 16 colpi di clock. Il ricevente “testa” lo stato del segnale in ingresso
ricercando uno start bit che segnali l’inizio della transazione. Una volta riconosciuto un
bit di start adeguato, segno dell’inizio della trasmissione, i bit riconosciuti
successivamente vengono immagazzinati nello shift register dedicato, che una volta
riempito, li rende disponibili (in fasci paralleli) al sistema ricevente del
microprocessore. L’USART setterà a questo punto una flag, rappresentata dalla
commutazione di un apposito bit (avviene proprio questo nel caso del nostro PIC), ad
indicare che nuovi dati sono disponibili e potrà inoltre dare origine ad un Interrupt .
Le operazioni che compongono la trasmissione sono più semplici perché controllate dal
microprocessore. Una volta depositati i dati nello shift register, l’hardware del modulo
di trasmissione genera lo start bit, shifta il numero richiesto di data bits fuori della linea,
se necessario genera il bit di parità, appone il bit di stop. Per la realizzazione della
comunicazione di tipo full duplex, nella quale la trasmissione e la ricezione possono
avvenire contemporaneamente, il modulo USART utilizza due registri separati per la
ricezione e per la trasmissione.
Adesso ritorniamo al modulo contenuto all’interno del nostro PIC16F628; questo può
essere configurato per garantire una comunicazione di tipo Asincrona full duplex (scelta
per la comunicazione del nostro device), Sincrona-Maser e Sincrona-Slave tramite il
setting di appositi bit. Per quanto riguarda invece i terminali di ingresso e di uscita,
vengono utilizzati, come è stato precedentemente detto, le linee RB1 per la ricezione e
RB2 per la trasmissione. Questi pin vengono dedicati alla periferica di comunicazione
seriale quando viene messo a 1 il bit SPEN appartenente al registro RCSTA di cui ci
occuperemo tra poco.
31
1.6.1 Il BAUD RATE GENERATOR
Un aspetto molto importante che caratterizza la comunicazione seriale tra due
dispositivi, è senza dubbio il Baud Rate. In generale con il termine Baud rate si intende
il massimo numero di variazioni che un segnale può subire in un secondo. Il Baud viene
spesso confuso con il bit al secondo, ma differisce da questo perché ad un Baud possono
corrispondere più bit se si usano più di due valori di ampiezza e si modula anche in fase.
Per generare l’opportuno valore di Baud rate desiderato c’è un generatore di clock
dedicato denominato BRG (Baud Rate Generator) che può essere utilizzato sia in fase
di ricezione che di trasmissione. Il periodo di clock è basato sul valore di un timer a 8
bit controllato dal registro SPBRG. In modalità asincrona Il Baud Rate Generator è
controllato anche dal bit BRGH appartenente al registro TXSTA per la selezione della
velocità, mentre in modalità sincrona questo bit viene ignorato. Quindi possiamo
riassumere che per impostare il valore desiderato di baud rate, e per definire in questo
modo la velocità di trasmissione, è necessario inserire un adeguato valore all’interno del
registro SPBRG e di impostare ad 1 o a 0 il bit BRGH a seconda che la comunicazione
avvenga ad alte o a basse velocità. Questi setting vengono operati all’interno del
firmware scritto (vedere a questo proposito la sezione dedicata al software redatto); ma
come è possibile calcolare il valore corretto da inserire nel registro SPBRG ? In questo
caso ci viene in aiuto il datasheet del PIC all’interno del quale sono fornite delle tabelle,
che ci restituiscono il valore cercato in base al valore della frequenza di clock collegato
al microcontrollore (FOSC) e al valore di Baud rate desiderato, e ci indicano una
formula per il calcolo esatto del valore da immettere nel registro interessato (a meno di
un errore stimabile).
Fig.1.14 – Il Baud Rate
Come si può vedere la presenza di una divisore 16 anziché 64 permette alla modalità ad
alta velocità di essere più accurata di quella a bassa velocità. Quindi, dove possibile,
utilizzare la modalità ad alta velocità anche per Baudrate bassi può portare a dei
32
vantaggi in termine di precisione. Vediamo i valori specifici utilizzati nel nostro
firmware per settare a 9600 il valore di Baud rate:
•
FOSC = 4 MHz (abbiamo scelto la frequenza dell’oscillatore interno del
microcontrollore)
•
Desired Baud Rate = 9600
•
BRGH = 1 (consideriamo la velocità di trasmissione abbastanza alta per minimizzare
l’errore)
•
SYNC = 0 (la comunicazione abbiamo detto è in questo caso di tipo asincrono)
Applicando la formula sopra riportata otteniamo un valore pari a 25 da immettere nel
registro SPBRG per ottenere le desiderate impostazioni di velocità.
33
1.6.2 Configurazione e registri
A questo punto analizziamo nel dettaglio i registri implicati in fase di ricezione e
trasmissione e che costituiscono il core del modulo USART.
I primi due registri, che contengono i bit utilizzati per settare tutte le impostazioni del
flusso trasmissivo sono TXSTA (Transmit Status and Control Register) e RCSTA
(Receive Status and Control Register)
Fig.1.15 – Transmit status and control register
34
Fig.1.16 – Receive status and control register
Riassumendo, il tipo di comunicazione scelta è di tipo asincrono, cioè i due terminali
non comunicano servendosi di un clock esterno per la temporizzazione del flusso dei
35
dati (se ne parlerà in modo più approfondito nella sezione dedicata al protocollo di
comunicazione). Per renderla tale basterà mettere a 0 il bit SYNC (TXSTA <4>). Una
volta impostata la modalità scelta, il modulo utilizza un protocollo standard Non Return
to Zero (NRZ) cioè ogni pacchetto sarà composto da un bit di start, uno di stop, otto o
nove di dati e nessun bit per il controllo di parità. Il baud rate come visto è preso dai
registri e dalle strutture dedicate.
Per quanto riguarda la fase di trasmissione, il registro shifter fondamentale, di cui si è
parlato nella parte precedente, è il Transmit Shift Register (TSR). È questo registro che
riceve i dati in formato parallelo dal TXREG, che viene caricato in base ai dati che
provengono dal programma in esecuzione nel microcontrollore. Lo schema a blocchi
presentato di seguito illustra il funzionamento in trasmissione del modulo USART.
Fig.1.17 – Schema a blocchi del funzionamento in trasmissione del modulo USART
Il registro shifter non viene caricato finché il bit di stop del precedente pacchetto non
viene inviato. Perciò appena il l’ultimo bit di un pacchetto (quello di stop appunto)
viene caricato nel TXREG, i dati vengono spostati nel registro di shifter, svuotando il
TXREG stesso e settando il flag bit TXIF (PIR1<4>). Il setting di questa flag avverrà
solo se in precedenza è stata abilitata la risorsa di interrupt legata alla trasmissione dati
(bisogna settare a 1 il bit TXIE nel registro PIE1). Il bit TXIF quindi segnala lo stato del
registro TXREG (accoppiando allo svuotamento del registro un interrupt), mentre un
altro bit, TRMT (TXSTA<1>), viene messo a 1 quando il registro di shift è vuoto, senza
però associare a questo avvenimento una fonte di interrupt. Il programmatore dovrà
perciò effettuare via software un polling continuo di questo bit per avere notizia dello
stato del registro shifter. La trasmissione non avrà inizio perciò finché il registro
36
TXREG non sarà stato riempito (una volta riempito questo registro i dati vengono
subito trasmessi al registro TSR e inviati automaticamente in trasmissione) e fino a
quando il Baud rate generator non avrà generato uno clock per lo shifting dei dati, ma
prima di tutto bisogna ablitare la trasmissione settando a 1 il bit TXEN (TXSTA<5>),
responsabile proprio dell’attivazione della funzionalità trasmissiva del modulo USART.
Il bit TX9D che compare nel blocco, viene invece chiamato in causa nel momento in cui
si voglia effettuare la trasmissione di pacchetti composti da 9 bit dati (TX9 = 1 in questo
caso).
Riassumiamo brevemente gli step seguiti per effettuare una trasmissione asincrona:
1. Inizializzare il registro SPBRG con un valore intero corrispondente al baud rate
desiderato;
2. abilitare la porta seriale asincrona mettendo a 0 SYNC e a 1 SPEN;
3. Se si desidera gestire interrupt relativi alla trasmissione dati, settare l’enable bit
TXIE;
4. se la trasmissione è di tipo 9-bit, TX9 verrà messo a 1;
5. abilitare la trasmissione settando TXEN;
6. caricare i dati nel registro dedicato TXREG (inizia la trasmissione).
La fase di ricezione è realizzata da un altro blocco di registri, schematizzati nella figura
seguente che funzionano in modo simmetrico rispetto a quelli dedicati alla trasmissione.
Fig.1.18 – Schema relativo alla fase di ricezione
37
I pacchetti vengono ricevuti dal pin RB1/RX e guidati al blocco di raccolta dati. Il
blocco di recupero è anch’esso formato principalmente da uno shifter che opera a una
frequenza 16 volte superiore a quella imposta dal Baud rate. Quando viene selezionata
la modalità asincrona, la ricezione deve essere abilitata tramite il setting del bit CREN.
Lo shift register in questo caso è chiamato RSR (Receive shift register). Anche in
questo caso, dopo aver ricevuto il bit di stop, i dati ricevuti dal RSR vengono trasferiti
nel registro RCREG, e una volta completato il trasferimento il flag bit RCIF viene
messo a 1 automaticamente fornendo l’input per l’interrupt legato a questa funzione
(previa abilitazione dello stesso tramite settino del bit RCIE). È proprio utilizzando
questo meccanismo che il nostro bit si “accorge” di un avvenuta trasmissione seriale da
parte dell’Host, gestendo la seguente risposta tramite una ISR (Inerrupt Service
Routine) scritta appositamente nel firmware. Il registro RCREG è un double buffered,
cioè è un registro a due livelli. Questo permette a due byte di dati alla volta di poter
essere ricevuti e di essere accumulati nel registro di ricezione.
Anche in questo caso, riassumiamo i passaggi da seguire per settare correttamente la
fase di ricezione:
1. Come nel caso precedente è necessario operare l’inizializzazione di SPBRG e
BRGH per quanto riguarda il Baud rate;
2. Abilitare la porta seriale in modalità async., azzerando SYNC e settando SPEN;
3. Per utilizzare le funzionalità di interrupt, attivarli tramite il bit RCIE;
4. Se si richiede una ricezione 9-bit, mettere a 1 RX9;
5. Attivare la ricezione, mettendo a 1 il bit CREN;
6. RCIF verrà impostato al valore 1 a ricezione avvenuta, generando
automaticamente un interrupt, se abilitato;
7. leggere gli 8-bit ricevuti dal registro RCREG.
38
1.7 Risorse di Interrupt
Abbiamo visto come il PIC sia dotato di registri dedicati alla gestione degli interrupt.
Ritorniamo brevemente su questo concetto: in informatica, un interrupt è un tipo
particolare di istruzione della CPU, che consente l'interruzione di un processo qualora si
verifichino determinate condizioni, oppure laddove il processo in esecuzione debba
effettuare una richiesta al sistema operativo. È un segnale, generalmente di natura
asincrona, che arriva all'interno della CPU per avvisarla del verificarsi di un certo
evento. In generale, gli interrupt vengono utilizzati quando:
•
un processo tenta di eseguire un'istruzione non valida, come una divisione per
zero. In questi casi non è possibile proseguire con l'esecuzione del processo e
l'interrupt consente di informare il sistema operativo di quanto avvenuto in modo
da permettere la corretta gestione del problema.
•
un processo richiede un'operazione di I/O al sistema operativo.
•
un dispositivo di I/O informa la CPU che è disponibile a ricevere o fornire dati.
In questo caso viene avviata un'opportuna procedura del sistema operativo
preposta ad occuparsi della relativa periferica.
In tutti questi casi e in molti altri, l’interrupt avverte alla CPU del presentarsi di un
evento, prodotto dalle periferiche o dal software stesso in esecuzione, e viene gestito dal
microprocessore tramite l’esecuzione di routine dedicate, salvando prima però nello
stack register. Al termine, il microprocessore torna all’istruzione che stava eseguendo
nel momento in cui si presentava l’interrupt, l’indirizzo corrispondente era stato infatti
salvato nello stack.
Proprio questo è quello che succede nel PIC nel momento in cui si verifica un interrupt
che però dovrà essere stato abilitato precedentemente nel firmware scritto. Abbiamo già
visto quali sono i registri che si occupano del setting e della gestione delle risorse di
interrupt che sono 10 nel 16F628:
•
External Inerrupt RB0/INT
•
TMR0 Overflow Interrupt
39
•
PORTB Change Interruptus (pins RB7:RB4)
•
Comparator Interrupt
•
USART Interrupt TX
•
USART Interrupt RX
•
CCP Interrupt
•
TMR1 Overflow Interrupt
•
TMR2 Match Interrupt
•
EEPROM
Ovviamente solo alcune di queste risorse sono state utilizzate durante la progettazione e
la realizzazione del firmware che costituisce il programma eseguito dal PIC.
Tutte le richieste di interrupt sono comunque raccolte tramite i flag bit del registro
dedicato INTCON che contiene anche bit per l’abilitazione degli interrupt in generale e
di singole risorse.
Il bit GIE di questo registro gestisce proprio l’abilitazione di tutti gli interrupt che
vengono gestiti singolarmente tramite i bit enable corrispondenti. Quando la CPU
risponde ad una richiesta di interrupt, il bit GIE viene azzerato, disabilitando ogni altro
interrupt, l’indirizzo di ritorno (ovvero l’indirizzo al quale corrisponde l’istruzione da
eseguire una volta usciti dalla routine di interrupt) era stato salvato, come detto, nello
stack register. Per gli interrupt legati ad eventi esterni (cambiamento del pin INT o di
PORTB) la latenza di interrupt corrisponde a tre o quattro cicli macchina.
Per un’analisi più approfondita di tutte le singole risorse di interrupt rimandiamo
all’esauriente datasheet del PIC. In questa sede ci interessa sapere che, a seguito di un
interrupt, il PIC esegue una particolare routine detta appunto di Interrupt nella quale
sono scritte le istruzioni che la CPU deve eseguire in questa fase.
La trattazione del codice presente in questa routine verrà presa in considerazione nella
sezione dedicata al firmware.
La sezione appena trattata ci ha esplicitato dettagliatamente come il microcontrollore
PIC16F628 costituisca la parte “intelligente” del nostro dispositivo: è proprio questo
integrato infatti, che gestisce gli input provenienti dall’utente disabile e rende possibile
quell’interazione
a
doppio
senso
che
rappresenta
il
nocciolo
innovativo
dell’applicazione realizzata.
40
2. LO STRATO FIRMWARE
2.1 Introduzione all’ Integrated Development Environment
Per lo sviluppo della componente software che andrà a costituire il firmware del
PIC16F628, è stato utilizzato l’ambiente di sviluppo MPLAB, fornito in modalità opensource dalla Microchip, il quale consente in prima analisi di redigere il codice sorgente,
e successivamente di svolgere accurate simulazioni emulando il comportamento del
microcontrollore programmato tramite lo stesso codice. L’IDE ( Integrated
Development Environment ) della Microchip permette di sviluppare codice scritto in
diversi linguaggi, supportando tutti i modelli di PICMicro presenti in commercio.
Figura 2.1. Microchip MPLAB IDE
41
MPLAB è una Windows like application di semplice utilizzo, che permette la
realizzazione di un progetto che renderà possibile la programmazione del componente
elettronico scelto e i successivi test. In particolare, per lo sviluppo del presente progetto
è stato scelto come linguaggio di programmazione il C, preferito al più diffuso e
utilizzato Assembly per via della maggiore semplicità e versatilità del linguaggio. La
programmazione e la creazione del codice deve seguire diverse fasi interdipendenti tra
loro che produrranno un file “.HEX” il quale verrà “bruciato” all’interno del PIC
tramite un apposito programmatore di cui parleremo più avanti.
Per svolgere quindi tutte le funzionalità, necessarie alla creazione di un firmware
funzionante che soddisfi le specifiche funzionali di progetto riportate in precedenza,
l’ide fornito dalla Microchip contiene, al suo interno, diversi tools:
ƒ
MPLAB Project Manager : consente di creare un progetto e lavorare con
specifici files. Grazie ad esso è possibile passare dalla creazione testo al Debug
del programma.
ƒ
MPLAB Editor : serve per creare il file sorgente o altri file di testo senza uscire
da MPLAB.
ƒ
MPLAB SIM Software Simulator : col simulatore è possibile eseguire ogni
singola riga di programma sorgente controllandone l’effettiva esecuzione.
ƒ
MPLAB Emulator : disponendo anche del supporto Hardware è possibile
effettuare delle emulazioni In-Circuit, testando direttamente sul circuito il
corretto funzionamento del programma.
42
Figura 2.2. Una delle fasi di sviluppo: la scelta del device
Per prima cosa si creerà un nuovo progetto specificando il tipo di PIC utilizzato e il
linguaggio di programmazione scelto. A questo punto, si procederà alla creazione del
codice sorgente tramite l’editor fornito dall’ambiente di sviluppo stesso che permette
semplicemente di eseguire il debugging del codice creato.
MPLAB ci permette inoltre, tramite delle opzioni di view, di visualizzare in tempo reale
il contenuto degli Special Function Register del PIC, potendo in questo modo verificare
come il firmware interagisca col microcontrollore modificandone il contenuto dei
registri.
43
Figura 2.3. Mplab permette di visualizzare il codice realizzato, l'output prodotto e il contenuto degli
Special Function Registers (SFR)
Una volta scritto e “debuggato” il codice sorgente, è opportuno testarlo grazie
all’utilizzo del modulo di simulazione MPLAB SIM che rende possibile simulare
l’interazione con gli input e gli output impostati per il PIC.
Alcuni tools, utilizzati durante lo sviluppo del presente progetto, permettono
effettivamente di impostare i pin di I/O su low/high-state, così da simulare l’azione di
particolari input collegati al microcontrollore, come ad esempio la connessione di
switch a pin di ingresso, che setteranno in stato basso i bit corrispondenti al momento
della chiusura dello stesso interruttore. Questa tipologia di interazione è resa possibile
dall’applicazione Stimulus, grazie alla quale è possibile creare inoltre dei veri e propri
file di input contenenti i settaggi da imporre ai pin di ingresso programmati
opportunamente.
44
2.2 Il Firmware
Passiamo ora alla descrizione del codice che costituirà il Firmware del PIC e che
contiene perciò, la sequenza di operazioni che il microcontrollore esegue all’avvio.
Prima di addentrarsi nella spiegazione tecnica delle singole righe di codice, è opportuno
descrivere brevemente la funzione primaria del codice stesso, che sarà ovviamente in
accordo con lo scopo realizzativo primario del seguente lavoro. L’applicativo software
scritto in linguaggio C si propone di programmare la componente hardware dotata di
intelligenza, rappresentata dal PIC16F628, in modo che quest’ultima possa
interfacciarsi col mondo esterno, tramite il collegamento seriale di input/output che la
connette all’Host, per mezzo di un attuatore generico, costituiente essenziale per un
ulteriore output del device, e tramite un input che svolgerà funzione di feedback
riguardo all’azione dell’attuatore.
Lo strato software provvede in prima istanza a settare i pin del PIC, che vengono in
questo modo impostati come input o output, e a rendere possibile, tramite il setting di
flags e parametri, la comunicazione seriale col Personal Computer lato utente (la
Control Station). Passiamo adesso all’analisi del codice vero e proprio.
Il listato, precedentemente descritto, è stato implementato in C, utilizzando le
potenzialità del compilatore PICLite presente all’interno dell’Ide MPLAB, che
permettono la creazione, lo sviluppo e il debugging di codice C. Come è stato accennato
in precedenza, di norma la programmazione PIC viene affrontata seguendo
preferibilmente la semantica dell’Assembly che dovrebbe permettere un maggior
controllo delle funzionalità Hardware, ma che risulta per ovvie ragioni più macchinosa e
meno intuitiva, motivi per i quali è stato scelto come linguaggio di sviluppo uno di più
alto livello, come il C appunto.
Iniziamo con la prima istruzione in codice che è rappresentata dalla direttiva “include”.
#include "htc.h"
Detta funzionalità comunica al compilatore di includere al posto della suddetta direttiva
l’intero contenuto della libreria “htc.h”. Questo libreria, incluso in realtà nel pacchetto
45
contenente l’Ide, contiene al suo interno le dichiarazioni necessarie al compilatore per
allocare e definire i registri e le variabili utilizzate nel listato in base alle peculiarità del
particolare PIC utilizzato. Ecco perché, per esempio, nel listato non vengono definite le
variabili indicanti i vari registri o i bit ( TRISA, TRISB, PORTB, etc etc.. ); le relative
definizioni con le allocazioni di memoria associate sono presenti quindi nella libreria
inclusa.
//Routine di ritardo Software
void waitdelay () {
int i;
for ( i = 0; i < 200; )
i++;
}
//Routine di ritardo Software
void waitdelay_2 () {
int i;
for ( i = 0; i < 500; )
i++;
}
Queste righe di codice hanno come finalità l’implementazione del ritardo software
tramite la scrittura di cicli for, che servirà più avanti nel listato, dove verranno
richiamate queste stesse funzioni. In particolare viene inizializzato un contatore “ i ” che
viene incrementato ad ogni ciclo, causando il ritardo detto “software” perché il
calcolatore non svolge nessun’altra operazione nel frattempo.
void main() {
Analizziamo a questo punto, il corpo del programma contenuto all’interno della
funzione principale main.
46
Per quanto riguarda la stessa funzione main, questa è dichiarata come void, ovvero essa
non ritornerà nessun valore specifico. Seguono a questo punto i setting che serviranno
ad impostare i pin di ingresso/uscita sia per il collegamento seriale, sia per quello verso
l’attuatore e l’input di feedback.
TRISB1 = 1;
TRISB2 = 0;
// Il pin RB1 di PORTB è configurato come input (RX)
// Il pin RB2 di PORTB è configurato come output (TX)
TXEN = 1;
RBPU = 0;
// Abilita la comunicazione attraverso l'USART
// Setaggio del pull-up su PORTB
TRISB5 = 1;
(switch)
TRISB0 = 0;
// Il pin RB5 di PORTB è configurato come input
RB0 = 0;
RB2 = 1;
// Il led viene settato su Spento
// Setting di RB2 (TX)
// Il pin RB0 di PORTB è configurato come output (led)
In particolare il primo registro, sul quale si agisce tramite il codice è il TRISB che, come
è stato ampiamente detto nelle sezioni precedenti, controlla e definisce la “natura” dei
pin appartenenti alla porta B. Infatti un valore assegnato su 1, farà si che il pin
corrispondente al particolare bit assumerà la funzione di INPUT, viceversa il valore 0
farà corrispondere il pin ad una porta di OUTPUT.
Nel nostro caso al bit 1 del registro TRISB viene associato il valore alto, perciò il
corrispondente pin RB1 verrà configurato come INPUT e servirà infatti da terminale di
ricezione ( RX ) per la comunicazione seriale con l’Host.
Analogo discorso vale per il pin RB2 che viene settato su low e servirà da OUTPUT (
per la trasmissione su seriale TX ). Il bit TXEN appartiene come visto al Transmit
Status and Control Register e, se impostato su 1, rende possibile la comunicazione
seriale tramite il modulo Usart implementato all’interno del PIC scelto appositamente. Il
bit RBPU dell’Option Register verrà settato sul valore 0 per attivare i pull-up interni
alla PORTB. In questo modo i pin impostati come Output sono inizializzati sul valore
alto.
B5 e B0 sono invece utilizzati rispettivamente come ingresso ( per lo switch/feedback )
e come uscita ( per il led/attuatore ) . Seguono le inizializzazioni di RB0 e di RB2.
47
Le righe successive implementeranno un aspetto molto importante del protocollo di
comunicazione utilizzato, ovvero il Baudrate, cioè la velocità con la quale sono
scambiati i dati tra trasmittente e ricevitore. In particolare il baudrate, misurato in bit per
secondo ( bps ), viene settato nel nostro caso su 9600 bps tramite il settaggio di appositi
registri che andiamo a individuare.
Per primo c’è il Baud Rate Generator Register ( SPBRG ) che, in base al valore su cui
viene impostato, determinerà la velocità di trasmissione.
Per il calcolo di suddetto valore ci viene in aiuto il datashet del PICmicro, che fornisce
una formula grzie alla quale è possibile settare correttamente il valore del SPBRG
conoscendo la frequenza di clock utilizzato per il microcontrollore e il valore di baud
rate desiderato.
Baud Rate = FOSC/(16(X+1))
La X contrassegna proprio la nostra incognita, cioè il valore decimale da immettere via
software nel nostro registro di controllo. FOSC indica la frequenza di oscillazione che
nelle nostre specifiche progettuali vale come già illustrato precedentemente 4 MHz ,
mentre il valore desiderato del Baudrate è appunto 9600 bps. Invertendo banalmente la
formula si ottiene il valore da caricare nel registro che nel caso considerato è 25. SYNC
è invece il bit 4 del registro TXSTA e settato a 0 permette una comunicazione di tipo
asincrono di cui si è già parlato in modo approfondito nella sezione riguardante il
protocollo RS232. In fine BRGH, anch’esso bit del Transmit Register , viene
posizionato a 1 per alti valori di baud rate, come nel caso di nostro interesse.
Il datashet del PIC riporta delle tabelle con i valori corrispondenti da caricare nel
registro generatore di baudrate al variare dei diversi valori di clock e di baud rate stesso.
// Imposta il Baud Rate a 9600 bps
SPBRG = 25;
SYNC = 0;
BRGH = 1;
48
Ricordiamo che per la progettazione del device si è scelto per motivi di semplificazione
di utilizzare il clock interno del PIC a 4 MHz, ma sarebbe stato possibile connetterlo ad
una fonte di clock esterno rappresentata da un quarzo o da un circuito oscillatore
equivalente di tipo RC. Riportiamo in fine le righe descritte.
RX9 = 0;
RCIF = 0;
seriale
RCIE = 1;
SPEN = 1;
CREN = 1;
// configura la ricezione a otto bit
// setto a zero il bit flag di ricezione del messaggio
// abilita l'interrupt per ricezione da seriale
// abilita la porta seriale
// abilita la ricezione continua in modalità Asincrona
Continua il setting dei vari flag per impostare la comunicazione seriale sui parametri
desiderati.
Il bit RX9 del registro RCSTA impostato su 0, fissa la grandezza del pacchetto inviato
a 8 bit.
Il nono bit serve per il controllo di parità, (maggiori chiarimenti a riguardo si ottengono
consultando la sezione sulla comunicazione seriale secondo il protocollo RS232).
Per quanto riguarda RCIF, questo è un è un bit facente parte del registro PIR1 che
contiene le flag degli interrupt. In particolare questo bit viene inizializzato a 0 ad
indicare che il buffer di ricezione è vuoto. Nel momento in cui suddetto buffer viene
riempito alla fine della trasmissione, il bit RCIF assume il valore 1 attivando l’interrupt
corrispondente, che verrà utilizzato più avanti nel listato per indicare l’avvenuta
ricezione del messaggio da parte del PICmicro.
RCIE impostato su 1 abilita l’utilizzo dell’interrupt di ricezione del modulo USART,
così da rendere possibile la discriminazione da parte del codice firmware dell’avvenuta
trasmissione di dati da parte dell’host.
SPEN e CREN fanno parte entrambi del registro RCSTA e servono rispettivamente ad
abilitare la porta il collegamento con la porta seriale, e a rendere attiva la ricezione
continua di bit tipica della modalità asincrona utilizzata in questo protocollo di
comunicazione.
49
PEIE = 1;
GIE = 1;
// abilita interrupt provenienti dalle periferiche
// abilita tutti gli interrupt
Questi due bit sono inclusi entrambi nel registro INTCON, che contiene tutte le flag per
l’attivazione delle risorse di interrupt di cui dispone il microcontrollore. PEIE rende
attivi tutti gli interrupt provenienti dalle periferiche e GIE abilita in generale tutti i tipi
di interrupt disponibili. L’interrupt nella specifica applicazione sviluppata permette al
PIC di “rendersi conto” della trasmissione del messaggio da parte dell’host e di
rispondere come da programma al presentarsi di questa evenienza.
A questo punto vediamo come avviene la prima comunicazione tra PIC e host. Il codice
permette al microcontrollore di inviare un primo messaggio di alive che nello specifico
è banalmente “CIAO”. Vediamo di seguito le righe di codice corrispondente.
// IL Pic invia un primo messaggio di alive
TXREG = 67;
// "C"
waitdelay();
TXREG = 73;
// "I"
waitdelay();
TXREG = 65;
// "A"
waitdelay();
TXREG = 79;
// "O"
waitdelay();
Il codice quindi non fa niente di più che caricare nel buffer di trasmissione ( TXREG )
un carattere che viene di conseguenza inviato via seriale all’host e aspettare un
determinato numero di cicli macchina dettato dalla routine waitdelay (), in modo da
evitare che il carattere successivo venga sovrascritto prima che avvenga la trasmissione
e che si incorra in questo modo in un errore da overrun del buffer di ricezione. Il
medesimo procedimento viene seguito per tutti i caratteri componenti il messaggio di
alive desiderato, che vengono inseriti nel codice utilizzando i corrispondenti valori
esadecimali secondo la nota codifica ASCII.
50
A questo punto analizziamo la routine contenente il controllo dell’interrupt, torneremo
sull’istruzione while subito dopo.
// Routine di interrupt
interrupt isr( void ) {
if ( RCIF == 1) {
// Ricezione seriale effettuata
if
(RB0 == 0){
RB0 = 1;}
else RB0 = 0;
TXREG = RCREG;
//Trasmette in echo il messaggio
ricevuto
La funzione è dichiarata void, cioè non ritornerà nessun valore, e contiene le istruzioni
che il microcontrollore dovrà eseguire una volta presentatosi l’interrupt legato
all’avvenuta ricezione del messaggio proveniente dall’Host. Questo interrupt era stato
abilitato quando avevamo settato ad 1 il bit RCIE e si presenta nel momento in cui il bit
flag RCIF viene settato; ciò avviene proprio nel momento in cui la ricezione del
messaggio è completata.
Come è stato già precedentemente descritto nella sezione riguardante le modalità di
ricezione e trasmissione seriale del PIC () perciò, una volta che la ricezione è completa,
e che quindi il relativo registro di ricezione RCREG è pieno, RCIF viene settato a 1
generando l’interrupt relativo alla ricezione, a questo punto il flusso del programma
seguirà proprio le istruzioni relative alla routine di interrupt.
In particolare, come si evince semplicemente dal codice, nel momneto di avvenuta
trasmissione del segnale da parte dell’host, il firmware procede alla commutazione del
bit RB0, collegato come è noto al LED ( o attuatore generico a seconda
dell’applicazione ) tramite un ciclo if e alla trasmissione in echo del messaggio ricevuto
copiando il contenuto del registro RCREG nel TXREG deputato proprio alla
trasmissione.
Analizziamo adesso le istruzioni contenute all’interno del ciclo while.
51
while( 1 ) {
if (RB5 == 1) {// A seguito del passaggio di RB5 nello stato
low
// A seguito del cambiamento di stato del bit RB5, viene inviato un
//messaggio sulla seriale
waitdelay_2 ();
TXREG = 0x20;
waitdelay_2 ();
TXREG = 0x42;
waitdelay_2 ();
TXREG = 0x2D;
waitdelay_2 ();
TXREG = 0x61;
waitdelay_2 ();
TXREG = 0x62;
waitdelay_2 ();
TXREG = 0x6C;
waitdelay_2 ();
TXREG = 0x65;
waitdelay_2 ();
// " "
// "B"
// "-"
// "a"
// "b"
// "l"
// "e"
Questa parte del codice implementa la capacità fondamentale del PIC di rispondere a
fronte di un input, costituito nella semplificazione da un semplice switch, che
rappresenta in realtà il feedback inviato dal sensore che intercetta e verifica l’attivazione
del generico attuatore. Il microcontrollore aspetta il verificarsi della condizione RB5=1,
corrispondente proprio alla pressione esercitata sullo switch, verificata la quale procede
all’invio di un messaggio via seriale caricato dal software all’interno del registro
TXREG ( nell’esempio il messaggio inviato all’host alla pressione del tasto è la stringa
“B-able” ). Tale messaggio servirà proprio da feedback lato utente di avvenuta
attivazione dell’attuatore, infatti verrà intercettato dal programma di interfaccia che lo
userà per individuare l’evento comandato dal soggetto.
Appena viene caricato col valore esadecimale corrispondente al carattere desiderato
secondo codifica ASCII, il registro TXREG provvede alla trasmissione dello stesso
sulla corrispondente linea seriale.
Da notare come si renda necessario fornire il tempo opportuno all’effettiva trasmissione
del carattere caricato nel registro software tramite l’interposizione di un ritardo (
implementato come visto da waitdelay ) così da evitare che possa essere caricato il
52
carattere successivo prima dell’avvenuta trasmissione del precedente mandando in
overrun il registro di trasmissione.
Proviamo quindi a riassumere le azioni che il microcontrollore esegue in base alla
programmazione ricevuta tramite il precedente codice.
Il PIC viene collegato serialmente ( seguendo il protocollo di comunicazione RS232 )
all’host, ad un output ( che lo connetterà all’attuatore ) e ad un input ( utile nel fornire il
feedback di verifica all’utente ). A seguito di una trasmissione seriale da parte del PC il
microcontrollore attiverà o disattiverà l’attuatore commutando il piedino RB0 e invierà
in echo il messaggio seriale ricevuto all’host stesso, a verifica dell’avvenuta
comunicazione. Il PIC è però capace di interfacciarsi anche col mondo esterno tramite il
piedino RB5, configurato come input. In questo modo il cambiamento di stato del bit di
input corrispondente provocherà la trasmissione di un messaggio all’host ( e quindi
all’utente ).
La seconda parte della transazione, quella che principia con il setting del bit di input,
viene utilizzata nel presente lavoro come verifica dell’effettiva attivazione dell’attuatore
con lo scopo di fornire all’utente un feedback relativo all’attivazione dell’attuatore
stesso.
53
2.3 Il Programmatore
A questo punto, una volta cioè scritto e verificato il firmware tramite gli appositi tool di
simulazione forniti dall’IDE, bisogna caricarlo all’interno del microcontrollore. A
questo scopo la Microchip fornisce degli appositi device ytilizzati a questo scopo
chiamati Programmatori. In commercio ce ne sono molti modelli, quello utilizzato nel
nostro progetto è il PICSTART Plus. La programmazione del PIC viene eseguita
semplicemente, a patto di collegare il programmatore al connettore seriale del personal
computer (in questo caso è stato utilizzato un convertitore USB-RS232 per ovviare alla
mancanza di porte seriali sui moderni PC), tramite una funzione apposita di MPLAB.
Basta impostare il programmatore utilizzato, inserire il PIC nello slot apposito e
procedere con il caricamento del file .HEX, prodotto dalla compilazione del programma
realizzato in MPLAB. Questo file contiene, infatti, la traduzione del codice in
esadecimale, garantendo al codice stesso maggior comapattezza.
L’operazione di burning è molto rapida e, una volta terminata, produce un PIC
programmato immediatamente utilizzabile.
Figura 2.4. Posiziono il PIC nel PICSTART Plus per caricare il firmware
54
3. I PROTOCOLLI DI COMUNICAZIONE
3.1 Le scelte progettuali
Nella fase progettuale, notevole importanza ha ricoperto la scelta dei protocolli di
comunicazione più adatti per implementare le caratteristiche del dispositivo che si
voleva realizzare.
Come abbiamo già detto nella parte introduttiva, l’ausilio nel suo insieme è un vero e
proprio sistema composto di diverse parti che comunicano tra di loro, con l’ambiente e
con l’utilizzatore finale. Nel nostro caso, è previsto senz’altro l’utilizzo di un personal
computer (opportunamente concepito e scelto tra quelli che garantiscono la
massimizzazione dell’accessibilità da parte di un utente disabile) che provvederà, sia a
fare da tramite tra l’utente e il dispositivo che opera l’attivazione degli attuatori
domotici, sia ad interpretare le informazioni di feedback provenienti dal device in modo
tale che queste possano essere recepite opportunamente dal disabile.
Perciò avremo l’utente che imposta i comandi sul PC (che verrà configurato per
diventare una vera e propria stazione di controllo) collegato in qualche modo al
dispositivo realizzato. Proprio questo tipo di collegamento deve essere scelto
opportunamente, secondo criteri discussi in questa sezione.
Nelle prime fasi di progetto si era pensato di realizzare un dispositivo che supportasse
un collegamento di tipo USB[7] con l’Host. Andando avanti nello sviluppo ci si è resi
55
conto che in questo caso, per gestire una periferica così concepita, sarebbe stato
necessario scrivere anche un driver apposito[8], compito assai difficile se non si
posseggono le opportune conoscenze informatiche. La connessione USB presentava
senza dubbio numerosi vantaggi tra i quali l’estrema diffusione di questa porta sui
moderni personal computer, l’elevata portabilità e la facilità di plug in. Per evitare la
redazione del driver, cioè di quel programma assembly che permette al sistema
operativo dell’Host di gestire i dati provenienti dalla periferica e la connessione con
essa, si era pensato in prima battuta di costruire un dispositivo USB appartenente alla
classe HID (Human Interface Device)[9] della quale fanno parte mouce e tastiere. Questi
dispositivi infatti vengono automaticamente riconosciuti al momento del plug-in e
vengono gestiti da driver generici già presenti all’interno di librerie dedicate, incluse nel
sistema operativo. Realizzare un dispositivo del genere avrebbe permesso di bypassare
l’onerosa scrittura del programma driver massimizzando inoltre la portabilità sella
periferica. Anche questa possibilità si è rilevata però inattuabile poiché realizzare una
periferica HID-USB comporta la registrazione a pagamento di un proprio Vendor-ID e
Product-ID che permettono il riconoscimento del dispositivo da parte dell’Host.
A questo punto ci si è rivolti verso il protocollo di collegamento seriale RS232, più
obsoleto, ma più semplice da utilizzare. L’uso del suddetto permette infatti di costituire
una semplice linea di comunicazione a tre fili (ricezione, trasmissione e massa) tra
l’host e il nostro device, sui quali vengono inviati e trasmessi i dati da e verso il
microcontrollore. Prevedendo questo tipo di collegamento solo lo scambio di dati, non
sarà necessario realizzare nessun tipo di driver per l’interpretazione dei dati.
Gli svantaggi di questo tipo di connessione sono rappresentati soprattutto dall’
obsolescenza della porta seriale, praticamente scomparsa sui personal computer attuali e
sui notebook.
In realtà, sebbene la modalità di connessione sia quella descritta dall’RS232, una
specifica del nostro dispositivo sarà senza dubbio quella di presentare caratteristiche
wireless. Nell’ottica di realizzare infatti una work-station portatile collegata a diversi
attuatori “intelligenti” capaci di azionare componenti domotici di vario tipo, disposti in
punti diversi dell’abitazione, il circuito a base microcontrollore dovrà implementare un
collegamento senza fili con l’host, costituente la stazione di comando vera e propria. Per
rendere possibile tutto ciò, si è ricorsi ad un componente, l’EZL-90 della Sollae System,
56
reperibile facilmente in commercio, capace di convertire la RS232 in Wi-Fi Lan.
Saranno quindi proprio questi due protocolli ad essere analizzati di seguito.
In fase di test inoltre per collegare il dispositivo direttamente al calcolatore, si è ricorso
ad un convertitore RS232-USB data l’assenza della porta seriale, soppiantata ormai
dall’Universal Serial Bus.
Siamo giunti quindi alla progettazione di un device sostanzialmente dotato di porta
RS232 e pensato proprio per sostenere una connessione di questo tipo con l’host, ma
che grazie all’aggiunta del modulo di conversione diventa a tutti gli effetti un modulo
senza fili Wi-Fi.
Di seguito si cercherà di analizzare i punti salienti di questi protocolli comunicativi.
3.2 RS-232
Il Recommended Standard 232 è costituito da una serie di protocolli meccanici, elettrici
ed informatici che rendono possibile lo scambio di informazioni a bassa velocità tra
dispositivi digitali di comunicazione per la connessione seriale cioè tra un terminale
DTE (Data Terminal Equipment) e un DCE (Data Circuit-terminating Equipment) [10].
Questo protocollo nato nel 1969 definisce:
•
caratteristiche dei segnali elettrici utilizzati come i livelli di voltaggo, il timing e
lo slew-rate, il massimo carico capacitivo;
•
le caratteristiche delle interfacce meccaniche, dei connettori e dei pin utilizzati;
•
la funzione di ogni circuito nelle interfacce di connessione.
Lo standard non si occupa di definire invece elementi come:
•
la codifica dei caratteri trasmessi sulla linea (ASCII, EBCDIC);
•
il framing dei caratteri nello stream dei dati (bit per carattere, bit di start e di
stop, parità );
•
protocolli per l’individuazione degli errori o per la compressione dei dati;
57
•
il bitrate per la trasmissione, anche se lo standard era pensato per bit rate
inferiori a 20000 bits per secondo, moderni device arrivano a bit rate di 115.200
bit/s.
I dettagli riguardanti la codifica utilizzata e il bit rate sono gestite dalla parte hardware
della serial port, spesso è un singolo modulo integrato chiamato USART (Universal
Synchronous Asynchronous Receiver & Trasmitter) che permette di trasformare il
segnale parallelo proveniente dal processore in segnale seriale e viceversa in ricezione.
Proprio la presenza di questo modulo nell’hardware del PIC ha rappresentato, come
detto, un criterio importante di scelta del microcontrollore. In genere vengono gestite
dall'hardware tutte le funzioni a basso livello necessarie (inserimento dei bit di start e di
stop, generazione o riconoscimento del bit di parità, generazione di interrupt) e spesso è
presente un buffer FIFO che permette di ricevere ed inviare dati anche quando la CPU è
impegnata (per la descrizione del modulo usart resente nel PIC consultare la sezione
relativa).
Tra gli utilizzi della porta seriale, si possono citare:
•
connessione di terminali ad un calcolatore (tradizionalmente un mainframe, ma
anche un PC);
•
connessione di periferiche:
o
la porta seriale è stata usata per collegare i mouse ai primi PC (sostituita
prima dalla PS2, poi dall’USB);
o
stampante (soppiantato dalla porta parallela, e poi da USB e dalle
stampanti di rete);
o
dispositivi specializzati, come ad esempio lettori di codici a barre e di
tessere magnetiche (soppiantato da USB);
•
connessione a dispositivi embedded, ad esempio dispositivi di rete, per scopi di
configurazione e monitoraggio. In questo utilizzo RS-232 è ancora ampiamente
usato, anche se spesso è necessario dotarsi proprio di un adattatore seriale/USB
per utilizzare come terminale un computer privo di porta seriale.
Nel corso di questi 40 anni lo standard si è evoluto pur mantenendosi in larga parte
invariato. L'evoluzione è riconoscibile dalla sigla, leggendo l'ultima lettera; l'ultima
revisione è del 1997 ed è indicata come EIA RS-232f. Probabilmente la versione più
58
diffusa è la RS232c, del 1969, corrisponde alle specifiche europee CCITT. Pur essendo
un protocollo piuttosto vecchio, attualmente la EIA RS-232 è ancora largamente
utilizzata per la comunicazione a bassa velocità tra microcontrollori, dispositivi
industriali ed altri circuiti relativamente semplici che non necessitano di particolare
velocità; è invece praticamente scomparsa in ambito "desktop", ambito nel quale lo
standard era nato per la comunicazione tra un computer ed un modem.
Le caratteristiche di natura elettrica previste[11] dallo standard consentono di acquisire le
poche informazioni necessarie a progettare dispositivi elettronici che comunicano con
un PC attraverso questa porta. I segnali che vengono supportati dal dispositivo sono di
tre tipi:
•
MARK: compresi tra -3 e -15 V;
•
SPACE: compresi tra +3 e +15 V;
•
INCERTEZZA: compresi tra -3 e +3 V;
L'interfaccia EIA RS-232 ridotta (ovvero solo asincrona) utilizza un protocollo di
trasmissione seriale di tipo asincrono.
Seriale significa che i bit che costituiscono l’informazione sono trasmessi uno alla volta
su di un solo "filo". Questo termine è in genere contrapposto a "parallelo": in questo
caso i dati sono trasmessi contemporaneamente su più fili, per esempio 8, 16 o 32.
Parlando astrattamente si potrebbe pensare che la trasmissione seriale sia
intrinsecamente più lenta di quella parallela (su di un filo possono passare meno
informazioni che su 16). In realtà, questo non è vero in assoluto, soprattutto a causa
della difficoltà di controllare lo skew (disallineamento temporale tra i vari segnali) dei
molti trasmettitori in un bus parallelo, e dipende dalle tecnologie adottate: per esempio
in una fibra ottica, in un cavo ethernet, USB o FireWire (tutti standard seriali) le
informazioni transitano ad una velocità paragonabile a quella di un bus PCI a 32 fili.
Asincrono significa, in questo contesto, che i dati sono trasmessi, byte per byte, in modo
anche non consecutivo e senza l'aggiunta di un segnale di clock, cioè di un segnale
comune che permette di sincronizzare la trasmissione con la ricezione. Ovviamente, sia
il trasmettitore che il ricevitore
devono comunque essere dotati di un clock locale per poter interpretare i dati. La
sincronizzazione dei due clock è necessaria, ed è fatta in corrispondenza della prima
transizione sulla linea dei dati.
59
Le unità di misura della velocità di trasmissione sono essenzialmente due: il baud rate
ed il bit per secondo (bps o, meno spesso, b/s), spesso trattate erroneamente come
sinonimi.
Il baud rate indica il numero di transizioni al secondo che avvengono sulla linea; il bps
indica, come dice il nome, quanti bit al secondo sono trasmessi lungo la linea.
Nel caso di trasmissione binaria (cioè è presente un livello alto ed uno basso) le due
cose ovviamente coincidono numericamente, da cui la parziale equivalenza dei due
termini. Nel caso di trasmissioni a più livelli, invece, è possibile trasmettere con una
sola transizione più bit: se per esempio posso trasmettere otto diversi valori di tensione
tra 0 ed 7 volt, con un solo valore di tensione invio tre bit (0 V = 000, 1 V = 001, 2 V =
010…) ed in questo caso una trasmissione a 1000 baud equivale ad una a 3000 bps.
Nel caso dello standard EIA RS-232 i livelli utilizzati sono due quindi il baud rate
coincide numericamente con il bps.
Vediamo adesso da vicino come è fatto un segnale EIA ER-232. La cosa più semplice
per descrivere un segnale EIA RS-232 è analizzare un esempio.
Figura 3.1 Il segnale EIA RS232
Nell’immagine è visualizzato, in modo idealizzato, cosa appare collegando un
oscilloscopio ad un filo su cui transita un segnale EIA RS-232 a 9600 bps del tipo 8n2
(più avanti verrà spiegata questa sigla) rappresentante il valore binario 01001011.
60
L’ampiezza del segnale è caratterizzata da un valore "alto" pari a circa +12 V ed un
valore "basso" pari a –12 V. Da notare che, nello standard EIA RS-232 un segnale alto
rappresenta lo zero logico ed uno basso l’uno, come indicato nel disegno, è quindi una
codifica a logica negativa, ossia rovesciata rispetto al comune pensare.
A volte un segnale alto (+12 V, cioè uno zero logico) è indicato come space ed uno
basso (-12 V, uno logico) come mark.
Tutte le transizioni appaiono in corrispondenza di multipli di 104us (pari ad 1/9600 cioè
ciascun bit dura esattamente l'inverso del baud rate).
La linea si trova inizialmente nello stato di riposo, alta (nessun dato in transito); la
prima transizione da alto a basso indica l’inizio della trasmissione (inizia il "bit di start",
lungo esattamente 104us). Segue il bit meno significativo (LSB), dopo altri 104 uS il
secondo bit, e così via, per otto volte, fino al bit più significativo (MSB). Da notare che
il byte è trasmesso "al contrario", cioè va letto da destra verso sinistra. Segue infine un
periodo di riposo della linea di almeno 208us, cioè due bit di stop e quindi
(eventualmente) inizia un nuovo pacchetto di bit.
Le varianti possibili sono le seguenti:
Se la trasmissione è più veloce o più lenta, la distanza tra i fronti varia di conseguenza
(p.e. a 1200 bps le transizioni avvengono a multipli di 0,833 ms, pari a 1/1200).
Invece di trasmettere 8 bit, ne posso trasmettere 5, 6, 7 o anche 9 (ma quest’ultima
possibilità non è prevista dalle porte seriali dei normali PC). Alla fine è possibile
aggiungere un bit di parità per l’error check. Alla fine la linea rimane nello stato di
riposo per almeno 1, 1.5 o 2 bit; notare che, se non c’è più nulla da trasmettere, il
"riposo" è molto più lungo, ovviamente. Molti sistemi non possono utilizzare 1.5 bit di
stop che venivano usati dalle telescriventi a 110 baud di velocità perché permetteva il
CR/LF (ritorno carrello/salto linea). In genere, nei personal computer, il formato del
pacchetto ricetrasmesso è indicato da una sigla composta da numeri e cifre, per esempio
8n1 e 7e2:
La prima cifra indica quanti bit di dati sono trasmessi (nei due esempi rispettivamente 8
e 7); la prima lettera , invece, si riferisce al tipo di parità (rispettivamente nessuna ed
even-parity, cioè parita pari); la seconda cifra è il numero di bit di stop (rispettivamente
1 e 2). Tenendo conto che esiste sempre un solo bit di start, un singolo blocco di bit è
61
quindi, per i due esempi riportati, costituito rispettivamente da 10 (1+8+0+1) e 11
(1+7+1+2) bit. Da notare che di questi bit solo 8 e, rispettivamente, 7 sono
effettivamente utili.
Nel tipo di trasmissione utilizzato nel lavoro, ogni pacchetto inviato e ricevuto dall’host
consta di 8 bit di dati (più uno di start all’inizio sempre presente), nessun bit di parità, e
1 bit di stop, cioè proprio una comunicazione 8n1. La velocità di trasmissione è invece
fissata ad un baud rate di 9600, cioè ci saranno 9600 cambiamenti di fronte al secondo.
Lo standard originale prevede una velocità da 75baud a 19200baud. Uno standard
successivo (RS-562) ha portato il limite a 64Kbps lasciando gli altri parametri elettrici
praticamente invariati e
rendendo quindi i due standard compatibili a bassa velocità. Nei normali PC le
cosiddette interfacce seriali RS-232 arrivano in genere almeno a 115Kbps o anche più:
pur essendo formalmente al di fuori di ogni standard ufficiale non si hanno particolari
problemi di interconnessione.
Ovviamente sia trasmettitore che ricevitore devono accordarsi sul modo di trasmettere i
dati prima di iniziare la trasmissione.
È importante garantire il rigoroso rispetto della durata dei singoli bit: infatti non è
presente alcun segnale di clock comune a trasmettitore e ricevitore e l'unico elemento di
sincronizzazione è dato dal fronte di discesa del bit di start. Come linea guida occorre
considerare che il campionamento in ricezione è effettuato di norma al centro di ciascun
bit: l'errore massimo ammesso è quindi, teoricamente, pari alla durata di mezzo bit
(circa il 5% della frequenza di clock, considerando che anche il decimo bit deve essere
correttamente sincronizzato). Naturalmente questo limite non tiene conto della possibile
difficoltà di riconoscere con precisione il fronte del bit di start (soprattutto su grandi
distanze ed in ambiente rumoroso) e della presenza di interferenze intersimboliche tra
bit adiacenti: per questo spesso si consiglia caldamente di usare un clock con una
precisione migliore dell'1% imponendo di fatto l'uso di oscillatori a quarzo.
Oltre ai bit dei dati (in numero variabile tra 5 e 9) viene a volte inserito un bit di parità
(opzionale), per verificare la correttezza del dato ricevuto. Esistono cinque tipi di parità:
None (come nel progetto): nessun tipo di parità, cioè nessun bit aggiunto; Pari (even): il
numero di mark (incluso il bit di parità) è sempre pari; Dispari (odd): il numero di mark
(incluso il bit di parità) è sempre dispari; Mark: il bit di parità vale sempre mark; Space:
il bit di parità vale sempre space.
62
Il bit di parità può essere LRC o VRC , cioè la funzione di parità, un XOR di a bit della
stringa dati incluso il bit di parità stesso, può essere eseguita sia lateralmente che
verticalmente sui dati inviati, ottenendo una stringa dati di parità finale con il relativo
bit di parità : il LRC di tale stringa dati di controllo deve combinarsi secondo le parità
precedentemente eseguite verticalmente che sul blocco VRC-dati creato.
Per quanto riguarda i parametri elettrici, la tensione di uscita ad un trasmettitore EIA
RS-232 deve essere compresa in valore assoluto tra 5 V e 25 V (quest'ultimo valore
ridotto a 13 V in alcune revisioni dello standard). A volte le tensioni in uscita sono
intenzionalmente diminuite a +/- 6 V anziché 12 V per permettere minori emissioni EM,
peraltro sempre critiche, e favorire maggiori velocità di trasmissione.
Il ricevitore deve funzionare correttamente con tensioni di ingresso comprese, sempre in
modulo, tra i 3 V ed i 25 V. Molti ricevitori commerciali considerano semplicemente
una tensione di soglia al valore di +2 V (sopra viene riconosciuto un segnale alto, sotto
uno basso) anche se ciò non è pienamente aderente alla norme. È però utile per
effettuare una trasmissione RS232 con livelli TTL come quelli prodotti proprio dalla
logica del nostro PIC.
L’impedenza di uscita del trasmettitore deve in ogni situazione essere maggiore di 300
ohm; l’impedenza di ingresso deve essere compresa tra i 3 ed i 7 kOHM, anche a
dispositivo spento. La corrente prelevabile in uscita mantenendo i corretti valori logici
deve essere di almeno di 1.6 mA (potrebbe però essere maggiore, anche di un ordine di
grandezza) e nel caso di corto circuito deve essere minore di 100 mA.
Infine lo slow-rate (cioè la pendenza del grafico del segnale nel passare da 1 a 0 o
viceversa) deve essere minore di 30 V/us per evitare eccessive emissioni
elettromagnetiche.
Un aspetto importante, di cui ci si è dovuti occupare durante la progettazione, è
rappresentato dal collegamento di una porta TTL o CMOS alla EIA RS-232. In genere i
segnali utilizzati dai sistemi digitali variano tra 0 e 5 V e non sono quindi direttamente
compatibili con la standard EIA RS-232.
In commercio esistono appositi traslatori di livello che hanno il compito di fornire sia in
trasmissione che in ricezione, gli opportuni livelli pur non modificando la forma del
segnale trasmesso. Nel nostro caso il traslatore di livello scelto è un integrato della
63
MAXIM, il MAX232 (figura) di cui ci occuperemo nelle sezioni seguenti, dedicate alla
realizzazione circuitale.
Figura 3.2 Il MAX232
Il MAX232 è un circuito integrato che permette il collegamento tra logica TTL o
CMOS a 5 V e le tensioni EIA RS-232, partendo solo da un'alimentazione a 5 V.
Analizzando infine i connettori, sul PC ne sono disponibili due tipi: DB9 (nove pin) e
DB25 (25 pin, il connettore originale e presente solo sui PC più vecchi); ambedue i
connettori sono maschi e praticamente identici dal punto di vista funzionale anche se
non coincidente con quello proposto dallo standard ufficiale (Inversione dei connettori
maschio / femmina che nello standard sono femmina).
Figura 3.3 Connettore DB9 Male
64
Di seguito, la tabella con indicati i nomi dei segnali, il numero dei pin e la direzione del
segnale
(O = uscita dal PC).
Sigla 25pin 9pin In/Out Nome
TxD 2
3
O
Dati trasmessi
RxD 3
2
I
Dati ricevuti
RTS 4
7
O
Request To Send
CTS 5
8
I
Clear To Send
DTR 20
4
O
Data Terminal Ready
DSR 6
6
I
Data Set Ready
RI
9
I
Ring Indicator
1
I
Data Carrier Detect
O
Trasmitting Clock
22
DCD 8
TC
15
GND 7
5
1
Massa
Schematura
Ora, la prima domanda che sovviene è: perché tanti fili? L'interfaccia EIA RS-232 è
nata con l'unico scopo di connettersi ad un Modem e quindi ha tutti i controlli per
gestire questa apparecchiatura. Tuttavia l'interfaccia viene spesso usata per connettere
direttamente fra di loro due PC e, in teoria per ricevere e trasmettere un segnale in modo
asincrono bastano tre fili: ricezione, trasmissione e massa (sono questi i collegamenti di
cui ci siamo preoccupati). Spesso, se si usa un programma di connessione che non
controlla gli altri segnali d'interfaccia, lo è anche in pratica.
Gli altri segnali (spesso opzionali, ma dipende dall’applicazione) servono per il
cosiddetto handshake tra PC e periferica (o tra PC e PC) cioè per sincronizzare in
hardware la comunicazione.
Sono presenti due coppie di segnali:
DTR/DSR: quando la porta RS232 è attivata per la prima volta dal programma, pone
alto DTR. La periferica risponde ponendo alto DSR.
RTS/CTS: quando il PC vuole iniziare la trasmissione pone RTS alto, la periferica
risponde quando pronta ponendo CTS alto. Per interrompere la trasmissione la
periferica pone CTS basso.
65
La corretta configurazione di un cavo incrociato null modem (che fa quindi la funzione
dei due Modem che dovrebbero interporsi fra i due PC) è la seguente:
Connettore A --------------- Connettore B
TX -------------------------> RX
RX <------------------------- TX
SG <-----------------------> SG
DTR--->DSR
DTR---->DSR
RTS-->CTS------------>DCD
DCD<-----------CTS<---RTS
Un uso alternativo dei pin RTS e DTR è l'utilizzo, come fonte di alimentazione, del
dispositivo collegato alla porta seriale stessa. L'esempio classico è il mouse seriale, ma
nulla impedisce di collegare un microcontrollore generico o qualche altro circuito.
Unico ed importante limite è la corrente erogata, visto che questi pin non sono pensati
per questo uso: è opportuno limitarsi ad una decina di mA . Attenzione che è una
sorgente non regolata e non protetta.
Altri segnali che citiamo a titolo “storico” perché attualmente sorpassati
tecnologicamente:
SQ Signal Quality, Qualità del segnale: proveniente dal DCE indica che il segnale in
arrivo è buono o non buono. In questo secondo caso è un "invito" ad abbassare la
velocità di trasmissione/ricezione.
STD Secondary Trasmit Data, Dati Trasmessi sul canale secondario di servizio; era un
75 bit/sec a cui faceva capo una telescrivente o simile terminale con cui gli operatori
comunicavano.
SRD Secondary Recive Data, Dati Ricevuti sul canale di servizio.
SRTS Secondary Request To Send, RTS del canale di servizio.
SCTS Secondary Clear To Send, CTS del canale di servizio.
Nel nostro caso non serve nessuno di questi pin. Come abbiamo detto, per realizzare
una connessione funzionale bastano tre fili e quindi tre pin: RxD, TxD e GND.
66
In fase di test inoltre il collegamento tra il dispositivo a microcontrollore e il personal
computer è stato gestito grazie al tool di Windows Hyperterminal, che gestisce proprio
connessioni di questo tipo e collegamenti via modem.
3.3 Il protocollo Wi-Fi
Una rete basata su cavi non è sempre la soluzione più pratica, spesso una connettività
wireless risolve i problemi legati alla mobilità ed alla flessibilità che richiediamo al
nostro accesso ad internet o alle risorse condivise da altri personal computer e server.
Un altro fattore che gioca a favore di questo tipo di connessione è quello economico:
dove non esistono cablaggi è decisamente meno dispendioso pensare ad una rete
wireless piuttosto che ad una tradizionale.
La tipologia di connessione di cui parleremo in queste righe è definita Wi-Fi,
abbreviazione di Wireless Fidelity, un termine che indica dispositivi capaci di collegarsi
a reti locali senza fili (WLAN)
[12]
basate sul protocollo IEEE 802.11. Questa famiglia
di protocolli include tre protocolli dedicati alla trasmissione delle informazioni (a, b, g);
la sicurezza è stata inclusa in uno standard a parte, 802.11i. Gli altri standard della
famiglia (c, d, e, f, h, …) riguardano estensioni dei servizi base e miglioramenti di
servizi già disponibili. Il primo protocollo largamente diffuso è stato il b; in seguito si
sono diffusi il protocollo a e soprattutto il protocollo g.
In particolare, quello utilizzato nel presente lavoro, è il protocollo Wi-Fi 802.11b, uno
standard di trasmissione che funziona alle frequenze di 2,4Ghz ad una velocità di
11Mbps. In pratica, un networking wireless Wi-Fi non è nient’altro che una rete
ethernet che trasporta i dati nell’etere, attraverso muri, soffitti ed anche strutture in
cemento, dal concentratore ai p.c., utilizzando una trasmissione in radiofrequenza in
luogo del tradizionale cavo. Inizialmente, nei primi anni '90 lo standard IEEE 802.11
indicava le specifiche fisiche per lo sviluppo di una rete LAN wireless, ovvero una rete
informatica a onde radio. Tale standard consentiva velocità fino a 2 Mbps usufruendo
della tecnologia basata ,come già detto, su onde radio a 2.4 GHz di frequenza o
direttamente su raggi infrarossi. Proprio la limitata velocità e la scarsissima diffusione
di apparecchi mobili (non era ancora in atto il boom della telefonia mobile) bloccarono
67
sul nascere lo sviluppo e la diffusione di questo stardard. Nel 1997 con l'evoluzione
tecnologica venne sviluppato un nuovo standard denominato, come già accennato, IEEE
802.11b ( Wi-Fi ) compatibile e molto simile al precedente, ma con una trasmissione
fino a 11 Mbit/s.
Nel 1999 le principali aziende del settore fondarono il WECA (Wireless Ethernet
Compatibility Alliance) al fine di ottenere una serie di standard comuni a tutti i
dispositivi, permettendo cosi la massima interoperabilità dei sistemi wireless.
Il protocollo IEEE 802.11b consente :
• un efficace adattamento della velocità di trasmissione con un range da 5.5 a 11
mbps a seconda del canale utilizzato;
• una velocità di trasferimento fino a 11 Mbps;
• un automatismo nella assegnazione della banda da occupare e dell'access point
di ingresso a seconda del traffico.
La rete a onde radio viene gestita attraverso alcune dispositivi denominati Access Point
(AP) e Wireless terminal. L'access point è in sostanza il gateway di connessione, ovvero
il punto di accesso alla rete wireless (quello che nella vita di tutti i giorni chiamiamo
router, in sostanza). Entro il suo raggio di azione gli utenti possono quindi collegarsi a
tutti gli apparecchi collegati nella stessa rete in una sorta di p2p a onde radio, salvo
limitazioni di accesso decise a livello software oppure collegarsi ad unità centrali come
in una normale rete Ethernet.
In un sistema wireless la trasmissione avviene,come abbiamo già detto, principalmente
via radiofrequenza (RF), nella banda ISM (Industrial Scientific Medical) attorno ai 2,45
Ghz utilizzando tecniche spread spectrum per ottenere una maggior robustezza nei
confronti dei segnali interferenti, o via infrarosso (IR). In questo tipo di trasmissione
vengono infatti utilizzate varie tecniche tra cui le principali sono: infrarosso , laser, via
radio .Nella trasmissione via radio due sono le tecniche principalmente impiegate:
•
trasmissione banda singola che utilizza tutta l'ampiezza di banda disponibile;
•
trasmissione a divisione di spettro, con trasmissione contemporanea di più
segnali con lo spettro suddiviso in più canali (Spread Spectrum appunto)
68
3.4 Il convertitore RS232 Wi-Fi, l’EZL-80
Come abbiamo detto, il nostro dispositivo è fondamentalmente di tipo seriale; è stato
dotato cioè di una comune porta DB9, tramite la quale viene messo in comunicazione
con l’host. Per rendere possibile una trasmissione senza-fili di tipo Wi-Fi è stato
aggiunto un modulo apposito che si occupa della conversione tra i due protocolli di
comunicazione. Il componente in questione è l’EZL-80c[13] prodotto dalla Sollae
System e commercializzato in Italia da Area SX.
La scelta di non realizzare direttamente un oggetto Wi-Fi, ma seriale, adattato in un
secondo momento alla comunicazione senza fili tramite l’aggiunta del modulo indicato,
proviene da diverse osservazioni fatte al momento della progettazione:
•
in primo luogo, mentre il PIC dispone di tutto l’hardware necessario per la
realizzazione
di
un
collegamento
seriale,
rendendone
agevole
l’implementazione, non è assolutamente predisposto per la comunicazione
senza fili;
•
la realizzazione di un comunicatore Wi-Fi si rivelerebbe senza dubbio molto
complicata anche per la difficoltà nel reperire gli integrati appositi;
•
questi moduli presenti in commercio hanno costi molto accessibili (si attestano
sui 30-40 euro), e una notevole semplicità di utilizzo incrementata dal software
specifico per il setting fornito dalla casa produttrice;
•
l’obiettivo di questo studio non è quello di realizzare un dispositivo di
conversione del genere.
Per questi motivi ci si è preoccupati di costruire un adeguato sistema comunicativo di
tipo seriale, assemblandolo in un secondo momento al dispositivo Sollae, così da
trasformarlo in un oggetto wireless. Vediamo adesso da vicino questo convertitore.
La serie ezTCP, che comprende il modulo utilizzato, è composta da dispositivi che
attuano la conversione generale serial-to-TCP/IP. Questa conversione permette a
qualsiasi dispositivo seriale di comunicare in rete, utilizzando un diverso protocollo di
trasmissione a seconda del tipo di ezTCP. Di seguito riportiamo un semplice schema di
funzionamento del dispositivo generico.
69
Figura 3.4 Convertitore EZL, uno schema di principio
In particolare, come spiegheremo in modo più dettagliato più avanti in questa sezione, il
tipo di connessione attuabile potrà essere di tipo network, utilizzando un AP (Access
Point), o di tipo Ad-Hoc o peer-to-peer, nella quale non è presente l’access point tra il
device e l’host.
Per quanto riguarda il modulo EZL-80 utilizzato, è caratterizzato da dimensioni ridotte e
permette la comunicazione TCP/IP attraverso il protocollo IEEE802.11b (Wi-Fi),
processando i dati provenienti dal collegamento seriale e inviandoli poi sulla wireless
LAN.
Figura 3.5 Modulo EZL80c. Top side, Bottom Side
70
Come si vede chiaramente in figura, il convertitore così definito non presenta prese
d’alimentazione e porte seriali, queste dovranno essere hardwarizzate essendo questo un
modulo embedded a tutti gli effetti. Per facilitare la realizzazione prototipale e le fasi di
collaudo perciò, il modulo è stato assemblato assieme al kit di sviluppo chiamato EZL90[14], completo di cablaggio per l’alimentazione e di porta seriale.
Figura 3.6 Il modulo EZL 90
Quindi il nostro modulo completo sarà formato dall’EZL-80, che è costituito, come si
vede da figura, dallo slot per CARD Wi-Fi, dall’insieme dei supporti hardware per
l’alimentazione (a 5V) per la connessione RS-232, dai led luminosi per il controllo del
corretto funzionamento del dispositivo come led luminosi e dal tasto di reset presente
sul modulo EZL-90.
Vediamo adesso da vicino quali sono le caratteristiche e le funzionalità dell’hardware
preso in analisi.
Per prima cosa, il modulo ha 16 pin, ognuno dei quali ha un nome e una funzione
indicata nella tabella seguente.
71
Figura 3.7 EZL 90. Pedinatura
Per quanto riguarda il controllo di flusso, utilizzato in caso di elevato flusso dati in
trasmissione/ricezione, la porta seriale dell’ EZL implementa il protocollo RTR/CTS
(ready to receive/clear to send). Il collegamento di questi pin tra ricevitore e
trasmettitore permette di salvaguardare i dati in caso di overflow sulla linea trasmissiva.
Sebbene ciò costituisca una funzionalità molto importante in alcuni casi, nello specifico
questi sistemi non verranno presi in considerazione, data la possibilità di controllare il
PIC tramite la trasmissione e la ricezione di un singolo carattere (a questo proposito
consultare l’apposita sezione). Quindi, in caso di mancato utilizzo di controllo di flusso,
per realizzare un collegamento efficace tra l’EZL e il microcontrollore, è sufficiente
connettere i pin RXD TXD e GND, in aggiunta ovviamente ad un opportuno
collegamento del pin 1 con l’alimentazione che dovrà fornire i 3.3V richiesti.
Avevamo già accennato all’esistenza di due diverse modalità tramite le quali è possibile
connettere in rete il convertitore, l’Infrastructure e la connessione Ad-Hoc. In modalità
infrastruttura è permessa la comunicazione tra più device wireless e l’host, tramite un
Access Point (tipicamente un router wireless), che smista la comunicazione stabilita tra
calcolatore e applicativi senza fili.
72
Figura 3.8 Configurazione Infrastructure
Proprio una connessione di questo tipo permetterà alla nostra powerstation di
controllare gli applicativi domotici installati nell’abitazione dell’utente diversamente
abile, tramite l’interfaccia accessibile del nostro sistema.
Il secondo tipo di connessione, denominato Ad-Hoc o peer-to-peer, non necessita
dell’interposizione tra l’host ed il device wireless di un router dedicato alla gestione
della comunicazione. In questo caso infatti c’è una corrispondenza univoca a livello
comunicativo tra il calcolatore ed il dispositivo senza fili. Le prime fasi realizzative
hanno sfruttato proprio questo livello di connettività, permettendo lo scambio dati tra il
dispositivo assemblato al modulo EZL e il calcolatore fornito di interfaccia apposita lato
utente.
73
Figura 3.9 Configurazione con collegamento Ad hoc
Lo schema sopra evidenzia come in questo tipo di configurazione non sia necessario
utilizzare alcun Access Point, l’unica specifica richiesta è quella di utilizzare, lato
utente, un personal computer fornito di connettività Wi-Fi, per realizzareil ponte radio
necessario.
Per effettuare setting di questo e altro in genere, assieme al convertitore viene fornito un
pacchetto software dedicato di facile utilizzo che consta di due programmi di setup:
ezSerialConfig e ezConfig, utilizzati rispettivamente per settare il dispositivo via seriale
e via wireless LAN.
La prima operazione necessaria, consiste nel collegare al personal computer il
convertitore tramite un cavo seriale di tipo null-modem (questo cavo, presentando
invertite le linee di trasmissione e di ricezione di un canale, permette la connessione tra
due dispositivi DTE) e di utilizzare il sw ezSerialConfig avendo cura di rimuovere la
card Wi-Fi dall’apposito socket. Questo programma permette di impostare quei
parametri essenziali per posizionare il dispositivo in rete, l’indirizzo IP da assegnare al
convertitore e i setting relativi alla porta seriale come il baud rate utilizzato dalla
trasmissione la presenza di bit di parità e di stop e del controllo di flusso.
74
Figura 3.10 ezSerial Config. Setup e settings
Vediamo più nel dettaglio quali sono le impostazioni da modificare in questa fase:
•
I parametri propri della connessione RS232 vengono impostati con questo
software, bisognerà perciò associare un opportuno baudrate (9600 nello
specifico), il numero di bit costituenti il singolo pacchetto, la presenza del bit
di stop e di un eventuale controllo di flusso.
•
È possibile determinare a questo punto, se la connessione sarà di tipo
infrastructure o ad-hoc.
•
Bisogna assegnare un identificativo di rete al dispositivo master (SSID) se si
utilizza la connessione punto-punto, oppure l’identificativo va associato
all’AP se la configurazione selezionata ne prevede la presenza.
•
Va selezionato il canale sul quale avverrà la comunicazione.
•
Se si desidera, si può includere una chiave per proteggere la connessione
agendo nel campo WEP;
Per quanto riguarda i parametri relativi al TCP/IP sono contenuti nella sezione MAC;
sarà quindi necessario associare al convertitore un indirizzo IP e una Subnet Mask,
necessaria per indicare che l’indirizzo del convertitore e dell’host appartengono alla
stessa sottoclasse.
75
In particolare, si è mantenuto l’indirizzo IP di default di valore 10.1.0.1 mentre i byte
componenti la subnet-mask avranno i seguenti valori 255.0.0.0.
L’operazione di settaggio deve concludersi con il salvataggio della impostazioni
all’interno del convertitore, che alla prossima connessione manterrà le caratteristiche
selezionate, tale operazione è realizzata dal tasto Write.
Il secondo software fornito dalla casa madre viene utilizzato soprattutto per testare le
funzionalità dell’EZL.
Figura 3.11 ezConfig, setting tramite WiFi
76
Figura 3.12 Funzione test
Alimentando l’ezTCP, una volta inserita la CF card (che costituisce sostanzialmente
l’antenna del convertitore), tramite l’ezConfig si entra nell’area test delle capacità
trasmissive del nostro convertitore tramite il tasto TEST, che permette di accedere ad
un’altra maschera con la quale è possibile inviare pacchetti dati e riceverne, così da
valutare l’efficienza della comunicazione seriale.
Per quanto riguarda le modalità di connessione, l’EZL ne supporta 4 diverse:
•
T2S, TCP to serial;
•
ATC, AT Command;
•
COD, Connect On Demand;
•
U2S, UDP to Serial.
Nella T2S, l’ezTCP funziona da server, ovvero aspetta di ricevere una richiesta di
connessione da remoto e la accetta quando questa proviene dalla local port predefinita
(selezionata tramite i precedenti software di setup), stabilendo la comunicazione TCP. A
questo punto viene attuato il processamento secondo TCP/IP sui dati provenienti dalla
77
porta seriale, trasmessi poi all’host remoto. Riportiamo lo schema di funzionamento di
questo tipo di connessione:
Figura 3.13 Connessione T2S
Perciò, quando la richiesta di connessione viene accettata dal serial-device, che funziona
in questo caso da server, inizia la comunicazione tra le due parti (metà inferiore dello
schema).
In modalità ATC, l’utente può controllare l’ezTCP tramite i comandi AT, come si fa nel
caso di un comune modem. Sia il server che il client possono essere in questo caso
configurati, tramite ad esempio l’assegnazione dell’address IP.
78
Figura 3.13 ATC, attiva e passiva
Nel modo COD, l’ezTCP funziona da client: è lui quindi che, nel momento in cui
arrivano i dati dal dispositivo seriale collegato, “richiede” la connessione all’host
remoto che questa volta fa le veci del server. Se quest’ultimo accetta la connessione,
viene stabilito a questo punto il protocollo TCP/IP
Figura 3.14 Connessione COD
79
Per ultimo analizziamo il modo U2S, nel quale il protocollo di comunicazione utilizzato
è l’UDP, che gestisce, come noto, la trasmissione di pacchetti di dati, a differenza del
TCP non c’è però il controllo dell’ordine dei dati, essendo in questo caso privilegiata la
velocità di trasmissione.
Figura 3.15 Connsessione U2S
Alla luce di questa breve descrizione, diciamo che la modalità utilizzata in questo studio
è stata sostanzialmente la prima, cioè TCP to Serial, nella quale l’host (cioè l’utente)
richiede la connessione all’EZL sulla local port (mantenuta a valore di default di 1470).
Il comportamento finale della rete sarà perciò quella di una connessione punto-punto o
peer-to-peer, scelta per gestire un singolo dispositivo seriale che si comporterà da
server, attendendo la richiesta di comunicazione da parte dell’host.
80
4. IL CIRCUITO DI CONTROLLO
4.1 Perché un device RS-232
Figura 4.1 Il circuito di controllo
In questo capitolo, dopo aver descritto e compreso come funzionano i componenti
principali, ci occuperemo della vera e propria realizzazione hardware del prototipo e
81
vedremo quali sono state le direttive di progetto seguite, l’assemblaggio complessivo
del prototipo e le relative fasi di collaudo.
La fase di progettazione hardware e di realizzazione software, legata alla redazione del
firmware
descritto
precedentemente,
devono
necessariamente
procedere
approssimativamente di pari passo: le performance richieste all’hardware, basato in
questo caso soprattutto sulla logica programmabile, dipendono necessariamente dalle
funzioni implementate dal microcontrollore che provengono a loro volta dal programma
che il PIC porta dentro la program memory dedicata. Per questo motivo la progettazione
del dispositivo fisico ha affiancato di pari passo lo sviluppo del firmware.
Un approccio iniziale prevedeva la realizzazione di un dispositivo che potesse
implementare un collegamento basato sull’Universal Serial Bus con l’host. Utilizzare un
protocollo del genere presentava, in prima analisi, vantaggi derivanti dalla elevata
portabilità dell’USB e dal grado di diffusione che questa tecnologia ha raggiunto negli
ultimi anni. In aggiunta a questo, il microcontrollore, basato su logica TTL (basata cioè
sull’utilizzo di transistori a giunzione bipolare sia per la realizzazione di porte logiche
che dell’amplificazione), utilizza tensioni di 5V per l’alimentazione e per i segnali di
input/output, gli stessi livelli di tensione utilizzati dall’Universal Serial Bus, facilitando
in questo modo un’eventuale connessione. Mentre, quindi, un’eventuale realizzazione
hardware caratterizzata da un dispositivo dotato di connessione di questo tipo con
l’host, non prevederebbe difficoltà, non si può affermare lo stesso per quanto riguarda la
redazione del firmware, concepito allo scopo di permette al microcontrollore la
comunicazione bidirezionale con host e attuatore. In questo caso la complicazione nasce
dal modo in cui la periferica USB e l’host vengono collegati dall’Universal Serial Bus.
Ogni qual volta si collega un dispositivo al personal computer tramite porta USB, com’è
noto, il sistema operativo ricerca un apposito programma associato al particolare
dispositivo, un cosiddetto driver, che permetterà all’OS di interpretare correttamente i
dati provenienti dal device USB e di stabilire con esso una comunicazione secondo gli
standard dettati dal protocollo usato. La scrittura di un driver d’altro canto risulta non
banale (e di scarso interesse nel presente lavoro) soprattutto per sistemi operativi come
Windows, nei quali il programma deve essere in grado di gestire l’accesso dei singoli
processi alla periferica. Per questo motivo si è deciso di tentare il bypass di questo
problema tramite la realizzazione di un dispositivo appartenente alla sottoclasse degli
HID (Human Interface Device). Un comune mouse moderno, piuttosto che una tastiera,
82
appartengono proprio a questa classe, e presentano la peculiarità di non richiedere la
redazione di driver dedicato, o meglio, il driver generico utilizzato per colloquiare con
questi device è contenuto all’interno dello stesso OS. Una volta collegati, vengono
come
noto
riconosciuti
automaticamente
dall’host
che
stabilisce
subito
la
comunicazione con questi dispositivi. Redigere quindi il firmware in modo tale da far
“passare” il device progettato da HID device potrebbe aiutare in prima analisi ad
aggirare il problema del driver. In realtà, dopo un’analisi approfondita della questione e
della tecnologia e in modo particolare proprio della sottoclasse di Human Interface, (a
questo riguardo è utile consultare il testo USB Designed by examples di John Hyde[8]),
un approccio del genere si è rivelato al pari inapplicabile. Il motivo risiede nella
necessita di registrare (a pagamento) presso la USB.org[7] un dispositivo di tipo HID,
ricevendo in questo modo un VendorID e un ProductID. Sono questi due parametri che
vengono utilizzati dall’OS per identificare il device al momento del collegamento della
periferica e del suo eventuale riconoscimento come Human Interface Device (questi due
parametri sono riscontrabili tramite la gestione dell’Hardware dal Pannello di Controllo
di Windows).
Per tutti questi motivi, la primitiva idea di affidarsi alla tecnologia USB per stabilire il
collegamento tra host e device realizzato è stata abbandonata, in favore del protocollo
RS-232 analizzato nelle precedenti sezioni.
Perciò il primo pensiero è stato quello di approntare il PIC per un collegamento seriale
di questo tipo. Mentre gli aspetti del software, o meglio, del firmware, sono stati già
ampiamente analizzati, in questo capitolo prenderemo in esame, come detto, gli aspetti
strettamente legati alla progettazione e realizzazione hardware.
Il primo aspetto preso in considerazione sarà perciò il tipo di componenti utilizzati per
rendere possibile la comunicazione seriale tra microcontrollore e personal computer.
83
4.2 Il circuito di connessione RS-232
Il primo problema che un tipo di connessione del genere porta con se, è rappresentato
dai livelli di tensione utilizzati dal protocollo in esame per la comunicazione sulla linea.
A questo proposito, per prima cosa è bene ricordare che non è possibile alimentare una
periferica tramite la stessa connessione RS232, come a volte avviene con l’USB,
bisognerà perciò prevedere, come è stato fatto per l’appunto nel progetto, uno stadio di
alimentazione dedicato, descritto più avanti in questa stessa sezione.
In seconda istanza, si è già parlato dei livelli di potenziale utilizzati per la trasmissione
dei dati su una siffatta linea (si veda a questo proposito il capitolo sui protocolli di
comunicazione) che sono caratterizzati, di solito, da livelli di voltaggio compresi in
valore assoluto tra i 3V e i 25V a seconda poi della revisione dello standard presi in
considerazione.
Nasce perciò la questione di come collegare una porta CMOS o, come in questo caso,
TTL alla EIA RS-232, dato che i segnali utilizzati da queste logiche hanno tensioni che
variano tra 0 e 5V, e non sono perciò direttamente compatibili con lo standard.
Per fornire i giusti livelli, sia in ricezione che in trasmissione, vengono utilizzati degli
appositi integrati in grado di rendere compatibili i segnali, pur non modificandone la
forma e quindi il contenuto informativo.
Sul mercato è disponibile una vasta gamma di integrati del genere alcuni dei quali
necessitano sia di alimentazione logica a 5V che di alimentazione duale a +/-12V
(MC1489 della Motorola). Questo integrato, come praticamente tutti i circuiti di questo
tipo, contiene un inverter per ciascun canale e quindi nel segnale in uscita o in ingresso
uno zero logico appare come 0 volt.
L’uso di questi integrati è semplice, ma non è sempre attuabile a causa della necessità di
disporre di tre alimentazioni, condizione non disponibile per l’applicazione in studio.
84
Figura 4.2 Il MAX232
Per questo motivo la scelta dell’integrato è ricaduta su un componente capace di
garantire maggiori performance, sotto questo punto di vista, ovvero il già citato
MAX232 della Maxim[15] (figura 4.2). Il suddetto IC (Integrate Circuit) permette appunto
il collegamento tra la logica TTL a 5V e le tensioni EIA RS-232, partendo da un’unica
alimentazione anch’essa a 5V. Come vedremo questo garantirà non poche
semplificazioni al momento della realizzazione dello stadio d’alimentazione. In pratica,
per ottenere la tensione positiva e negativa, necessaria per il funzionamento
dell’integrato è utilizzata una configurazione a “pompa di carica”, costituita da circuiti
interni all’integrato e 5 condensatori esterni di circa 1uF. I valori effettivi delle capacità
dipendono dal tipo di integrato e dalla relativa frequenza di commutazione. La stazione
ricevente del MAX232 è costituita da due porte invertenti che accettano in ingresso una
tensione di +/- 12 V (o altra tensione compatibile allo standard EIA RS-232) ed in uscita
hanno un segnale TTL compatibile. La sezione trasmittente ha due driver invertenti con
in ingresso TTL compatibile e capaci di erogare a vuoto una tensione di poco meno di
+/- 10 V, compatibile con lo standard EIA RS-232. Per ricavare le tensioni positive e
negative necessarie per garantire i livelli richiesti dalla RS232 è pratica comune
utilizzare un duplicatore ed un invertitore di tensione a pompa di carica.
85
.
Figura 4.3 Meccanismo di funzionamento basato su capacità
Le figure A e B mostrano come viene ottenuto il raddoppio della tensione.
Un’immagine che rende l'idea è quella di un contenitore (C2) che preleva acqua da una
fonte e la riversa in un secondo contenitore (C1) posto a maggiore altezza. Più in
dettaglio:
•
Inizialmente il condensatore C2 viene connesso tra massa e Vcc; quindi la
corrente (in blu) carica C2 alla tensione di alimentazione (in giallo). Quindi Vc2
= Vcc;
•
C2 viene successivamente connesso tra Vcc ed un secondo condensatore C1; la
tensione ai capi di C1 deve essere uguale alla somma di Vcc e Vc2 e quindi C2
si scarica verso C1, che aumenta la propria tensione rispetto a massa
•
Il processo è ripetuto fino a quando la tensione ai capi di C1 è uguale a 2Vcc: in
questo caso infatti C2 non si può più scaricare.
Da notare che, nel funzionamento normale, il processo non può mai interrompersi in
quanto il carico collegato a C1, non disegnato, assorbe corrente e quindi tende a
scaricare C2 stesso. Analogamente le figure C e D mostrano l’inversione di tensione:
•
Inizialmente C2 è caricata alla tensione di alimentazione (magari, come nel
disegno da 2Vcc, ricavata con il circuito precedente)
•
Quindi C2 è connesso tra massa e C1 avendo cura di invertire le polarità. In
questo modo C1 si carica a –2Vcc;
86
Il limite dei circuiti a pompa di carica è la limitata quantità di corrente disponibile:
infatti se prelevo da C1 corrente, questo tende a scaricarsi, facendo scendere la tensione;
la corrente generata da un circuito integrato tipo MAX232 è generalmente tutta
utilizzata per il solo funzionamento del driver e quindi non è disponibile per altri
circuiti. Ecco uno schema estrapolato dal datasheet del componente, nel quale sono
riportati i collegamenti da realizzare per l’utilizzo desiderato.
Figura 4.4 Pin e collegamenti del MAX232
Per riassumere quindi è necessario, nel caso in cui si desideri far comunicare un
microcontrollore a logica TTL tramite uno standard RS232, interporre un integrato del
tipo descritto per ottenere un adeguato adattamento dei livelli di tensione, per ulteriori
specificazioni sull’integrato della Maxim rimandiamo comunque al datasheet della casa
costruttrice. Di seguito, riportiamo lo schema dei collegamenti effettuati (il seguente,
come tutti gli altri schemi elettronici presenti in questo lavoro sono stati redatti grazie al
cad apposito Orcad), al fine di improntare il desiderato tipo di connessione del PIC. I
condensatori collegati al MAX232 sono stati dimensionati in base alle specifiche
riportate sul datasheet del componente e permettono proprio quelle performance di
elevatore/invertitore di tensione proprie dell’IC preso in esame.
87
Figura 4 Schema ORCAD del circuito di controllo
88
CONNECTOR DB9
P1
1
6
2
7
3
8
4
9
5
10u
C5
1n
C4
1u
C3
1u
C2
8
7
6
5
4
3
2
1
R2IN
T2OUT
V-
C2-
C2+
C1-
V+
C1+
MAX232
R2OUT
T2IN
T1IN
R1OUT
R1IN
T1OUT
GND
VCC
C1
1u
U1
9
RESET
1
9
10
2
8
7
6
5
4
3
2
1
11
12
13
14
15
16
12K
R1
RA0/AN0
RA1/AN1
PIC16F628A
RB3/CCP1
RB7/T1OSI/PGD
Vdd
RA6/OSC2/CLKO
RB4/PGM
RB5
RB6/T1OSO/T1CKI/PGC
RB2/TX/CK
RB1/RX
BR0/INT
Vss
RA5/MCLR/Vpp
RA4/TOCKI/CMP2 RA7/OSC1/CLKI
RA3/AN3/CMP1
RA2/AN2/Vref
10
11
12
13
14
15
16
17
18
1.7K
R2
100n
C6
OUTPUT CONTROLLO
INPUT FD
5V
Dallo stadio d'alimentazione
Analizzando lo schema qui proposto, ritroviamo le funzioni dei pin illustrate sia nel
capitolo riguardante il PIC che in quello legato alla stesura del firmware. In particolare,
notiamo come i pin RB1 e RB2 (i numeri 7 e 8) vengono utilizzati per la ricezione (Rx)
e la trasmissione (Tx) dei segnali provenienti e destinati all’host (verranno quindi
collegati ai pin corrispondenti del MAX232 che fa da tramite). Per quanto riguarda il
segnale di Output del microcontrollore, quel segnale cioè che permetterà al circuito di
controllo di comandare l’applicativo, è stato scelto come terminale di uscita il pin RB0;
la porta che fornirà invece traccia dell’attività proveniente dal mondo esterno è
rappresentata dal pin RB5. È importante ricordare che questi collegamenti non fanno
altro che tradurre a livello hardware le impostazioni settate nel firmware, è nella fase di
programmazione infatti che i pin vengono destinati ad Input o ad Output. Le sezioni di
circuiteria, collegate a loro volta a questi terminali, che ancora non compaiono nello
schema, verranno prese in esame in dettagliato più avanti.
A sua volta, l’integrato della Maxim è collegato al connettore DB9 tramite i pin 13 e 14
(T1OUT e R1IN che insieme compongono uno dei due canali dell’IC). Oltre alla
connessione con la massa di riferimento, non sono necessari altri collegamenti per
stabilire una comunicazione su protocollo EIA RS-232, non essendo richiesta
l’implementazione di nessun sistema di controllo sui pacchetti trasmessi, che
richiederebbe infatti fili aggiuntivi (per esempio il sistema RTS/CTS).
Entrambi gli integrati ricevono un’alimentazione a 5V, in corrispondenza degli appositi
piedini, che viene fornita da uno stadio separato realizzato a parte, anche questo
analizzato tra poco.
Per quanto riguarda la realizzazione fisica dei collegamenti, per questa parte del
progetto, come per tutte le restanti componenti descritte in seguito, si è proceduto con
una cosiddetta tiratura a mano dell’hardware su schede millefori standard, con
componenti aventi case e piedinatura adeguati allo scopo.
Da una prima fase di pianificazione dei collegamenti e degli schemi elettronici da
realizzare, resa possibile dall’utilizzo di programmi di disegno automatico dedicati, si è
passati ad una fase di test su scheda breadbord, tramite la quale è stato possibile mettere
alla prova i componenti e le connessioni, per poi dedicarsi ad un’accurata tiratura a
mano cercando di rendere il più possibile massimizzate le caratteristiche funzionali, di
compattezza ed estetiche del prototipo. In figura 5, la cornice in rosso individua la
porzione contenente i due integrati, sia sulla faccia superiore della scheda millefori, che
89
di quella retrostante dove risiedono la maggior parte dei collegamenti effettuati tramite
saldature a stagno.
Figura 4.5 Nel riquadro in rosso MAX232 e PIC16F628, lato superiore.
Figura 4.6 Lato saldature.
90
Una volta improntato un primo circuito comprendente la connessioni funzionali tra il
PIC16F628, il MAX232 e la porta DB9, verificate preliminarmente le stesse con l’aiuto
di un multimetro in grado di individuare la presenza degli opportuni cortocircuiti e
collegata infine opportunamente l’alimentazione, si è proceduto ad una prima fase di
test.
Un’importante osservazione, di carattere tecnico, è legata alla mancanza, oramai quasi
costante, di connettori RS-232 su desktop e notebook. Abbiamo già detto che questa
tecnologia è stata resa obsoleta dall’avvento del protocollo USB, che ne ha reso
irreperibili le porte sulla stragrande maggioranza dei personal computer. A tutto questo
si può ovviare abbastanza semplicemente ricorrendo a un convertitore commerciale
USB-RS232, capace di fare da ponte tra i due protocolli. Si presenta in realtà come un
semplice cavo che ha ad un’estremità un connettore USB, e all’altra un connettore DB9
“male” (Figura 7). In realtà questo particolare dispositivo si basa a sua volta su un
integrato dedicato: l’ FT232, concepito appositamente per dispositivi di conversione di
questo tipo. Questo ha permesso una quantomai semplice connessione del dispositivo
appena realizzato con l’host che “vede” la porta USB collegata al convertitore come una
vera e propria porta COM, tipica della connessione RS-232. fig
Figura 4.7 Convertitore USB-RS232
A questo punto si è ricorsi ad un programma incluso nel OS Windows atto
all’emulazione della comunicazione seriale, ovvero Hyperterminal. Tale software ha
permesso di simulare la connessione desiderata e di effettuare sia la trasmissione che la
ricezione di segnali seriali tra l’host e il device. In figura, riportiamo una schermata
tratta proprio da questo applicativo.
Innanzitutto Hyperterminal permette di settare tutti i parametri della comunicazione,
come il numero di bit inviati, la presenza del bit di stop, il baudrate. Dal capitolo sui
91
protocolli di comunicazione sappiamo di dover utilizzare un baudrate pari a 9600, con
una comunicazione di tipo 8n1, senza alcun controllo di flusso.
Figura 4.8 Schermata di prova Hiperterminal. In rosso il messaggio di alive (CIAO), in verde caratteri in
echo, in blu il messaggio legato all'input (B-able)
A questo punto possiamo accertare il corretto funzionamento del nostro hardware: i
caratteri mandati a schermo infatti, costituiscono la traccia echo voluta dei caratteri
inviati al PIC, programmato proprio per ritrasmetterli a sua volta all’host al momento
della ricezione. È visibile il messaggio di alive che il PIC trasmette all’host quando
viene collegato e quando viene premuto il tasto di reset.
92
Figura 4.9 Collegamenti per collaudo con Hiperterminal (rosso). In blu la connessione tramite
convertitore all'host, in giallo collegamento d'alimentazione.
In questa prima fase di testing, il collegamento opportuno del tester, ci ha permesso di
verificare che, nel momento in cui il microcontrollore riceve un carattere dall’host, il
pin dedicato al controllo dell’output (RB0) viene messo nello stato logico 1 (il
multimetro misurerà 5V sul pin). Per quanto concerne l’input del PIC, che dovrà
provenire dal feedback dell’attuatore, a questo livello è stato simulato con un semplice
interruttore che, se premuto, collega il pin predefinito RB5 ai 5V dell’alimentazione,
emulando in questo modo un segnale proveniente dall’esterno. Come scritto sul
firmware, in corrispondenza dell’input, il PIC invia all’host un messaggio tramite il
collegamento seriale. In questo caso il messaggio è “B-able”, come si vede chiaramente
dalla schermata di prova del terminale di Windows. Questo messaggio verrà intercettato
dal programma di interfaccia e elaborato in modo tale da essere recepito dall’utente
finale.
93
4.3 Lo stato di pilotaggio del carico
A questo punto cominciamo a parlare del lato attuatore. Anticipiamo che ci occuperemo
in una sezione dedicata della scelta dell’applicativo vero e proprio realizzato e della
descrizione delle possibili soluzioni demotiche improntabili. A questo livello ci
interessa descrivere il modo in cui un carico di qualche tipo, verosimilmente alimentato
dalla normale rete domestica, possa essere pilotato dal circuito di controllo.
La soluzione più immediata è quella di utilizzare la tensione messa sul pin dal
microcontrollore per controllare l’alimentazione stessa del carico. Per ottenere questo
risultato è opportuno utilizzare un semplice relais commerciale, avente le opportune
caratteristiche. Queste ultime sono legate alla tensione e alla quantità di corrente erogata
dal microcontrollore della Microchip. In particolare, grazie al datasheet, constatiamo
che il microchip è capace di erogare 25mA al massimo, ad una tensione, come detto di
5V. Da queste osservazioni deriva che, la corrente prodotta dallo stadio di uscita del
microcontrollore non sarebbe da sola sufficiente per eccitare la bobina di un comune
relais commerciale (circa 80-100 mA per i relais più comuni). Anche se esistono relais
in miniatura con correnti di 15mA è comunque sconsigliabile collegarli direttamente
alle uscite del PIC, poiché le extratensioni di apertura possono superare le diverse
migliaia di Volt, distruggendo gli stadi di uscita del chip (una bobina in cui scorre
corrente genera un campo magnetico; togliendo l’alimentazione il campo magnetico
induce una corrente che, se non si chiude su nessun carico, porta ad un incremento della
differenza di potenziale ai capi della bobina). Per questo motivo, e per rendere possibile
l’utilizzo di un relais commerciale con bobina da 5V, viene aggiunto allo stadio di
uscita del PIC un transitor e giunzione bipolare. Il BJT viene utilizzato come un
interruttore, in grado di moltiplicare la corrente che scorre sulla base, amplificandola sul
contatto di collettore in relazione alle proprie caratteristiche e al dimensionamento dei
componenti resistivi.
In particolare, il transistor è stato scelto tra quelli capaci di erogare almeno quei 100mA
di corrente necessari ad eccitare la bobina, mentre lo schema circuitale dei collegamenti
è riportato nella seguente figura.
94
220V
1
3
12V
2
Alimentazione Attuatore
A
B
Relay_ Finder 40 .51
R3
54
C
R4
OUTPUT PIC
Q1
B
4K
Q2N1711
E
Figura 4.10 Schema Orcad Stadio di pilotaggio del carico
Una volta disegnato lo schema circuitale, si è passati alla scelta dei componenti e al
dimensionamento delle resistenze. Per quanto riguarda il relais, ne è stato scelto uno
della Finder, il 40.51[16]. Possiede una bobina da 5-6V con 80mA di assorbimento
minimo, capace di pilotare carichi di 240V e 6A (idoneo quindi per controllare un
qualsiasi carico domestico).
95
Figura 4.11 Il relais 40.51 della Finder. Foto e schema dei contatti.
In figura oltre ad un’immagine del relais stesso, è riportato lo schema dei pin. A1 e A2
servono a fornire la differenza di potenziale necessaria all’attivazione della bobina,
mentre i pin 11 12 e 14 sono utilizzati per il collegamento del carico, e in particolare
dell’alimentazione sullo stesso, che viene collegata dal relais al momento
dell’attivazione della bobina.
Il transistor è un comune 2N1711[17], in pratica, i 5V provenienti dal microcontrollore
fanno commutare il BJT dallo stato di interdizione a quello di saturazione, permettendo
lo scorrimento della corrente desiderata dal terminale di collettore (e quindi dal relais) al
terminale di Emettitore connesso a terra.
In base allo schema illustrato precedentemente, per determinare le resistenze di Base
(R4) e di Collettore (R3), si risolvono banalmente le due equazioni delle maglie
considerando:
•
V BE e VCE , rispettivamente cadute di tensione tra Base ed Emettitore e tra
Collettore ed Emettitore in saturazione, valgono ,in base al datasheet del
componente, 0.95V e 0.5V;
96
•
il guadagno in corrente hFE vale circa 130 (con corrente di 150mA di corrente di
collettore);
•
La caduta di tensione ai capi del relais ( Vr ) vale 5V;
•
La corrente di collettore IC deve ammontare almeno a 90mA per garantire
l’eccitazione della bobina.
Considerando inoltre che, lo stadio di uscita del PIC al quale colleghiamo il terminale di
Base del transistor produce 5V, e che il relais è collegato ad un generatore a 12V
(l’alimentazione
merita
una
trattazione
separata),
possiamo
schematizzare
i
collegamenti come segue, per procedere alla risoluzione delle maglie.
12V
Vr
Relais
IC
RC
C
RB
B
5V
IB
VBE
E
VCE
Figura 4.12 Schematizzazione del circuito di pilotaggio per il dimensionamento dei componenti
12V − Vr − I c Rc − VCE = 0
5V − I B RB − V BE = 0
12V − 5V − I c Rc − 0,5V = 0
5V − I B RB − 0,95V = 0
I c Rc = 6,5V
RC ≅ 70Ω
IB >
IC
> 0,7 mA ⇒ I B = 2mA
hFE
RB ≅ 2 KΩ
97
Per quanto riguarda la realizzazione circuitale, in una prima fase il transistor e il relais
per il controllo del carico appartenevano alla stessa basetta millefori. In un secondo
momento si è invece deciso di includere il 2N1711 nella stessa millefori del circuito di
controllo per separare i due stadi. Quest’accorgimento avrebbe permesso di considerare
il carico completamente indipendente dallo stadio di controllo che, come richiedono le
specifiche, deve mantenere un elevato grado di indipendenza e di universalità. Nella
figura possiamo ritrovare nella sezione evidenziata i componenti legati allo stadio di
controllo a transistor.
2
1
Figura 4.13 Nel riquadro rosso i componenti che realizzano lo stadio di pilotaggio.
98
1
2
Figura 4.14 Collegamenti lato saldature. La freccia individua il pin RB0
Oltre ai collegamenti e ai componenti, sono evidenziate due uscite a pin-jack. Il numero
1 serve a collegare l’output su RB0 (individuato dalla freccia rossa) con il lato attuatore,
tramite l’interposizione dello stadio transistor. Con l’uscita numero 2, l’alimentazione a
12V viene portata al relais per realizzare la configurazione riportata nello schema di
figura 4.10.
Analizziamo a questo punto lo stadio di alimentazione.
4.4 Lo stadio di alimentazione
Descriviamo adesso lo stadio di alimentazione e le scelte progettuali compiute per
arrivare fino ad esso. Per prima cosa, diciamo che il progetto, costituito dal lato legato
allo stadio di controllo e uno
relativo all’attuatore, prevede la presenza di due
alimentazioni separate. Onde garantire una facile istallazione infatti, è necessario ridurre
al minimo indispensabile gli interventi da praticare sull’attuatore, che è un comune
dispositivo domestico collegato all’alimentazione di rete, come un impianto per
l’illuminazione o un comando motorizzato per l’apertura di porte o serrande. Per
collegare lo stadio di controllo all’applicativo vero e proprio, basterà collegare il
99
conduttore di fase di quest’ultimo al relais che, controllato tramite i circuiti visti
precedentemente dal microcontrollore, deciderà l’accensione e lo spegnimento
dell’azionamento stesso.
LATO CONTROLLO
LATO ATTUATORE
FEEDBACK
P
I
C
ATTUATORE
220V
12V
12V
5V
Segnale di Feedback
Figura 4.15 Schema dei collegamenti tra Lato Controllo e Lato Attuatore
Nella figura precedente, è schematizzata proprio la separazione dei due stadi, ognuno
dotato di propria alimentazione.
Per quanto riguarda lo stadio di controllo, esso necessita fondamentalmente delle
seguenti tensioni di alimentazione:
•
5V per la tecnologia TTL del microcontrollore;
•
+/-10V per il protocollo seriale EIA RS-232;
•
12V per la realizzazione del circuito relais + transistor dello stadio di controllo
del carico;
Per quanto riguarda i valori di tensione per la comunicazione seriale, abbiamo visto
come essi sono forniti dal MAX232 a partire da soli 5V. Rimangono quindi i 12V e i
5V che vengono unificati tramite un apposito componente: l’LM7805[18].
100
Riportiamo a questo proposito lo schema elettrico dello stadio di alimentazione.
330n
VOUT
2
5V Alimentazione PIC
C8
3
C7
VIN
GND
LM7805
1
12V
100n
Figura 4.16 Schema Orcad stadio di alimentazione
Figura 4.17 Componenti dello stadio di alimentzione. La freccia individua l'LM7805
Grazie a questo componente possiamo alimentare il circuito di controllo con 12V
ottenuti tramite un comune alimentatore
stabilizzato (cioè capace di fornire una
tensione di alimentazione continua costante rispetto sia alle variazioni del carico che a
quelle dell’alimentazione) che fornisce in output 12V e 1A max.
Il 7805 riceve quindi in ingresso i 12V, e fornisce in uscita i 5V che potranno essere
collegati al microcontrollore alimentandolo correttamente. I 12V provenienti
dall’alimentatore verranno destinati inoltre a sezioni specifiche che necessitano di questi
valori di voltaggio come il circuito di controllo del relais (che in realtà appartiene al
circuito dell’attuatore) e il circuito che realizza il feedback (consultare la sezione
dedicata alla realizzazione dell’attuatore).
Le capacità presenti nello schema vengono collegate per evitare problemi relativi
all’oscillazione delle tensioni di alimentazione e sono dimensionate in base ai valori
presenti sul datasheet del componente utilizzato.
101
Vediamo di seguito come appare lo stadio di alimentazione realizzato sulla basetta
millefori.
12V
12V
5V
5V
Figura 4.18 Nel riquadro rosso i componenti dello stadio di alimentazione. Le frecce indicano il percorso
delle alimentazioni
12
5
5
12
Figura 4.19 Vista Lato saldature
102
Per riassumere quindi, i 12V in ingesso vengono sia convertiti in 5V tramite il suddetto
componente per alimentare la logica TTL, sia trasferiti allo stadio di controllo relais per
comporre i collegamenti necessari per il controllo dell’eccitazione della bobina.
4.5 Il Pin RB5
A questo punto parliamo del pin RB5 utilizzato dal PIC16F628 per ricevere l’input dal
circuito che fornisce il feedback al circuito di controllo. Come è stato riportato nel
capitolo riguardante il firmware, quando un pin deve essere utilizzato da input, bisogna
settare in modo opportuno il registro corrispondente (TRISB in questo caso), e deve
essere attivato sullo stesso pin un pull-up interno. Il pull-up consiste nel collegare ai 5V
dell’alimentazione il pin tramite una resistenza interna al microcontrollore. Questa
configurazione serve a mantenere costante lo stato del pin (sull’1 logico in questo caso)
che, configurato come input, dipende solo dallo stato della circuiteria esterna, e
potrebbe essere influenzato da qualsiasi interferenza, non necessariamente collegata al
segnale di input vero e proprio. Quindi con questo sistema il pin viene tenuto a 1 (5V), e
il suo passaggio allo stato 0 (0V) costituisce il segnale di ingresso. Nel caso considerato
però, la circuiteria esterna al microcontrollore è realizzata in modo da fornire una
tensione di 5V come segnale (vedremo poi come), non intercettabile come input valido
dal pin RB0 del microchip che si trova già sui 5V. Per ovviare a questa situazione, è
stato aggiunto un ulteriore pull-down esterno al piedino RB0, che lo collega a massa
tramite una resistenza dimensionata ad hoc. In questo modo il pin si trova nello stato
logico 0 finché non riceve in ingresso un segnale consono, proveniente dalla circuiteria
esterna. Come resistenza è stato utilizzato un trimmer per poterne modificare a caldo il
valore, per garantire a RB0 un valore di tensione che corrisponda allo 0 logico.
103
RB
INPUT
INPUT
RB0
PIC16F628
Figura 4.20 Schema di collegamento di RB5. Foto dei componenti reali
In questo modo RB0 è mantenuto a 0 (in realtà la differenza di potenziale tra il pin e
terra non è 0 perché c’è una resistenza interposta tra i due terminali, ma è abbastanza
bassa da rientrare nello stato logico low) finché non riceve in ingresso il segnale,
proveniente dalla circuiteria esterna, che consiste nel feedback dell’attuatore.
4.6 Passare al Wireless
Le sezioni precedenti hanno permesso di descrivere la struttura e le diverse componenti
del circuito di controllo. Riassumendo, siamo giunti alla realizzazione di un prototipo
che è in grado di comunicare con l’host tramite protocollo RS232. Grazie a questa
connessione, il device può ricevere segnali dal personal computer, e quindi dall’utente,
e inviare a sua volta comandi alla parte applicativa. Le modificazioni sull’ambiente
risultanti, vengono captate e comunicate indietro fino all’utente stesso. Si muovono
quindi i primi passi verso la realizzazione di un vero e proprio sistema che permette alla
persona disabile di interagire con l’ambiente domestico in modo bidirezionale. Prende
forma l’idea di una vera Power-Station, rappresentata dall’PC munito di interfaccia
consona alle possibilità residue dell’utente, collegata col circuito di controllo (uno per
ogni attuatore domotico considerato) che funge da mediatore tra la volontà del soggetto
104
e le diverse applicazioni poste all’interno dell’abitazione. In altri termini prende forma
la bozza di un vero e proprio sistema domotico.
Per rendere effettivamente funzionale un sistema del genere, tuttavia, è necessario
integrare un’altra funzionalità nel nostro circuito basato su microcontrollore. Oltre al
basso costo, alla facilità di istallazione e all’universalità, è necessario implementare una
comunicazione wireless con l’host.
Per fare questo ci riferiamo al componente descritto nella sezione precedente, ovvero al
modulo EZL-80 della Sollae System.
Figura 4.21 Il modulo EZL-90 nel complesso con card WLAN inserita (riquadro in rosso)
Come è stato ampiamente formalizzato, questo particolare convertitore permette ad un
dispositivo RS232, di supportare il protocollo Wi-Fi, permettendone la comunicazione
su radiofrequenza con l’host grazie all’apposita WLAN card a 16bit inserita
nell’apposita slot. È stato già detto che il modulo EZL-80 vero e proprio, essendo un
modulo embedded, non è fornito di collegamenti già pronti per quanto riguarda la porta
seriale o l’alimentazione, richiederebbe quindi di cablaggi ad hoc che lo rendano
collegabile con l’hardware che si desidera rendere wireless. Per questo motivo,
esclusivamente per comodità legate alla fase di collaudo, il modulo convertitore è stato
acquistato assieme ad una piattaforma di sviluppo che, pur ampliandone un poco le
dimensioni (commisurate comunque a quelle di una basetta 100mm X 60mm), ne rende
estremamente semplice ed immediato il collegamento sia allo stadio di alimentazione
che a quello di trasmissione seriale. L’EZL-90 (così si chiama il convertitore della
105
Sollae munito di estensione) è fornito infatti di un comune ingresso a pin-jack per
l’alimentazione e di un connettore DB9-male.
Una curiosità interessante, emersa durante l’analisi del datasheet del modulo di
conversione, è legata alla presenza, all’interno dello schema circuitale, dell’integrato
MAX232, utilizzato anche in questo caso per rendere possibile il collegamento tra la
logica TTL, presente nell’embedded della Sollae, e le tensioni proprie del protocollo
EIA RS232. Verosimilmente, è un microcontrollore dedicato che provvederà alla
conversione seriale-WiFi, grazie alla scheda WLAN card che esplica le funzioni
necessarie di antenna in radiofrequenza.
Ritornando al circuito di controllo, dotato di un connettore DB9 a sua volta, è stato
facilmente collegato al convertitore dotato inoltre di led che riportano traccia delle
attività di trasmissione/ricezione dati (figura).
Figura 4.22 Il modulo EZL-90 viene connesso al cirduito di cotrollo tramite il connettore seriale ed il pin
di alimentazione
Nelle prime fasi di sviluppo l’alimentazione del convertitore, che necessita di 5V con
un assorbimento di 250mA, veniva prodotta da un alimentatore dedicato, fornito dalla
stessa casa produttrice un comune stabilizzato a 5V capace di erogare al massimo 1A).
106
Per minimizzare però il numero di alimentatori necessari al circuito di controllo,
essendo l’alimentazione del convertitore equivalente a quella richiesta dal
microcontrollore, si è modificato lo schema circuitale per utilizzare per entrambe le
sezioni il medesimo stadio di alimentazione (figura). A questo scopo si è aggiunto alla
basetta principale un pin complementare con l’ingresso del convertitore, così da
permettere il passaggio dell’alimentazione e la connessione dei due stadi. Vediamo
quindi cosa otteniamo da questo collegamento. La configurazione finale è caratterizzata
dall’hardware di controllo, pensato come device RS232, connesso tramite connettore
DB9 al modulo di conversione, che non fa altro che “tradurre” i segnali, provenienti dal
device a lui collegato, in segnali radio (grazie alla scheda CF) e trasmetterli all’host.
Viceversa il personal computer (la stazione di controllo a questo punto), tramite il
proprio hardware dedicato per la trasmissione wireless, invia su Wi-Fi messaggi al
convertitore della Sollae che li rende concordi al protocollo RS232 e li passa al circuito
di controllo. Si realizza in questo modo una comunicazione bidirezionale su Wi-Fi tra
l’host e il dispositivo seriale realizzato. Questo permetterà il decentramento del device
di controllo, rispetto alla postazione di comando dalla quale partono i comandi
provenienti dall’utente disabile.
Una volta collegati quindi i due sistemi, ci si è dedicati alla fase di collaudo della
comunicazione wireless. Come abbiamo visto precedentemente, un modulo di
conversione del genere, necessita di alcuni setting per rendere conseguibile la
comunicazione desiderata tra i terminali interessati. I programmi forniti a questo scopo
dalla casa madre sono stati ampiamente descritti precedentemente (sezione relativa ai
protocolli di comunicazione), ricordiamo brevemente che il primo passo è quello di
collegare il convertitore tramite cavo incrociato all’host e, agendo tramite il software
ezSERIALconfig, si procede a settare i parametri propri della comunicazione che
verranno caricati in questo modo dal firmware presente nel modulo EZL al momento
della connessione. Diciamo inoltre che, disponendo di un solo prototipo e convertitore
associato, permetteremo all’EZL di realizzare una connessione punto-punto (ad hoc)
con la stazione di controllo, non sarà quindi necessario disporre di un Access Point
(realizzabile comunque tramite un normale router Wi-Fi reperibile facilmente in
commercio). Per testare il nostro circuito in relazione alla configurazione senza fili, si è
ricorsi all’applicazione di un semplice led alla porta di output, per verificare in modo
immediato che la trasmissione del pacchetto spedito dall’host su radiofrequenza fosse
107
effettivamente ricevuto dal microcontrollore, producendo le risposte programmate nello
stesso (figura). A questo scopo si è utilizzato in modo proficuo la sezione di test del
software ezCONFIG che ha permesso di visualizzare proprio i caratteri in entrata e in
uscita dal modulo EZL.
La prima operazione da eseguire, al fine di stabilire una connessione funzionante è
quella, ovviamente, di attivare la scheda Wi-Fi del personal computer che funge da host
tramite gli appositi tool di configurazione del sistema operativo. Se il convertitore
funziona correttamente, tra le reti senza fili disponibili, ne comparirà una di tipo
computer-to-computer non protetta (non è stata impostata nessuna chiave WEP per
l’EZL) con identificativo corrispondente al SSID, cioè quell’identificativo (Service Set
Identifier) che serve ad individuare un dispositivo su una rete Wlan e che viene
associato al convertitore in fase di configurazione (nel caso specifico il SSID è test).
Ricordiamo che la configurazione del convertitore, descritta nel capitolo precedente, è
avvenuta in una fase precedente, perciò sono state già impostate le caratteristiche della
comunicazione seriale (bit per pacchetto, bit di stop, controllo di parità, etc.), la
configurazione di tipo punto-punto e lo stesso SSID. Nella sezione relativa al test basta
introdurre l’indirizzo IP corrispondente al convertitore, e il port number utilizzato per lo
scambio dei pacchetti.
È interessante constatare che proprio il tool di test, presente nel software di
configurazione, presenta al suo le funzionalità fondamentali sulle quali è stato basato il
programma di interfaccia in Visual Basic che costituirà l’interfaccia utente. Ci
occuperemo di quest’ultimo argomento, proprio nel capitolo successivo.
108
5. L’INTERFACCIA UTENTE IN VISUAL BASIC
5.1 Obiettivi dell’interfaccia
Nel seguente capitolo ci occuperemo di descrivere l’interfaccia, realizzata
appositamente, che permetterà all’utente di interagire semplicemente con l’host, e
quindi, con la Control Station del sistema ausilio realizzato. La funzione primaria del
SW redatto sarà quella di potenziare l’accessibilità del personal computer, così da
permettere ad un’utenza disabile di disporre del pieno controllo del sistema ausilio.
Per la programmazione necessaria è stato scelto il linguaggio orientato agli eventi
Microsoft Visual Basic 6, che introdurremo brevemente di seguito. L’obiettivo
dell’interfaccia sarà inoltre quella di gestire il collegamento Wi-Fi che deve instaurarsi
tra host e circuito di controllo, permettendo lo scambio di dati necessario al corretto
funzionamento del sistema.
109
5.2 VB6, Programmazione basata sugli eventi
Figura 5.1 Visual Basic 6
Esistono centinaia di linguaggi di programmazione, ciascuno dei quali è stato sviluppato
per risolvere un particolare tipo di problema. La maggior parte dei linguaggi
tradizionali, come BASIC, C, FORTRAN etc, sono considerati linguaggi procedurali.
Ciò significa che il programma specifica l’esatta sequenza di tutte le operazioni. La
logica del programma determina la successiva istruzione da eseguire, in risposta a
condizioni e a richieste dell’utente. I linguaggi di programmazione più recenti come
C++ e Visual Basic, utilizzano un approccio diverso: la programmazione orientata
agli oggetti e la programmazione basata sugli eventi. Microsoft considera Visual
Basic un linguaggio basato sugli eventi, che ha molti elementi di un linguaggio
orientato agli oggetti come Java. Nel modello basato sugli eventi, i programmi non sono
più di tipo procedurale, in quanto non seguono una sequenza logica[19]. Il
programmatore non mantiene il controllo e non determina la sequenza di esecuzione.
Invece, ogni azione dell'utente, come la pressione di un tasto o il clic del mouse su un
pulsante, può provocare l'attivazione di un evento, che determina l'esecuzione di una
routine o procedura Basic implementata dal programmatore. Ad esempio, se l'utente fa
click su un pulsante di comando con l'etichetta calcola, ciò causa l'attivazione del
relativo evento click, e il programma salta automaticamente a una routine che è stata
110
scritta per eseguire tale operazione di calcolo. In Visual Basic si lavora con oggetti, che
hanno proprietà e metodi: si può pensare a un oggetto come a una cosa o un sostantivo.
Esempi di oggetti sono form e controlli. I form sono le finestre dell'applicazione e le
relative finestre di dialogo che si collocano sullo schermo; i controlli sono gli elementi
che si inseriscono all'interno di un form, come le caselle di testo, i pulsanti di comando
e le caselle di riepilogo. Le proprietà forniscono informazioni relativamente a un
oggetto, come il suo nome, colore, dimensione, posizione o comportamento. Si può
pensare alle proprietà come ad aggettivi che descrivono gli oggetti. Quando si fa
riferimento a una proprietà prima di tutto si indica il nome dell'oggetto, quindi si
aggiunge un punto, e poi il nome della proprietà. Ad esempio, si può fare riferimento
alla proprietà Caption di un form chiamato Form1 digitando Form1.Caption.
Le azioni associate agli oggetti sono chiamate metodi. I metodi sono i verbi della
programmazione orientata agli oggetti. Alcuni metodi tipici sono Print, Move, Clear e
Resize. La sintassi di riferimento per i metodi è del tipo Oggetto.Metodo: ad esempio,
un metodo Print può essere applicato a diversi oggetti, Printer.Print invia l'output
all'oggetto stampante, Form1.Print invia all'output il form chiamato Form1.
La realizzazione di un progetto Visual Basic è suddivisa in tre fasi, che implicano la
progettazione dell'interfaccia utente, la definizione delle proprietà e la creazione del
codice.
1. Nella fase relativa alla progettazione dell’interfaccia utente, vengono creati i
form e i controlli previsti durante la fase di pianificazione del progetto. Vengono
quindi definiti in questo momento tutti gli oggetti utilizzati nel progetto.
2. L’impostazione delle proprietà degli oggetti consiste nell’assegnare loro un
nome e definire attributi come il testo di un’etichetta, la dimensione del testo e le
parole che appaiono su un pulsante di comando o nella barradel titolo di un
form,
3. Per svolgere le azioni necessarie dal programma si utilizzeranno istruzioni Basic
(chiamate codice Basic). Per creare un programma potente possono essere
necessarie anche poche istruzioni.
111
Sono state queste le fasi seguite durante la realizzazione del programma di interfaccia
che avrà un ruolo cruciale nel funzionamento del sistema ausilio. Sia per la sua funzione
di mediare tra utente e host, amplificandone l’accessibilità, sia per l’aspetto funzionale
che implementa la connessione efficace tra Control Station a applicativi domotici via
Wi-Fi, fondamentale per il corretto funzionamento del sistema.
5.3 B-SERIAL, l’interfaccia utente
La stesura del software di interfaccia è, al pari della realizzazione dell’hardware, un
elemento cruciale per la creazione del sistema ausilio oggetto del seguente studio.
L’interfaccia costituisce infatti l’unico contatto che l’utente disabile ha con l’ambiente
composto dagli attuatori domotici. E proprio tramite questo mezzo dovrà essere in grado
di interagire con essi in modo bidirezionale. Al software vengono quindi delegate le
funzionalità di comando e di switching sensoriale che permettono l’integrazione delle
abilità dell’utente stesso.
Oltre a questo aspetto, ne rimane un altro, forse ancor più importante almeno dal punto
di vista funzionale, che è quello relativo alla necessaria connessione che deve instaurarsi
tra host e circuito di controllo (e quindi attuatore). Tale comunicazione dovrà essere
senza dubbio stabile e conforme ai parametri presenti nel protocollo utilizzato. A questo
scopo la redazione del software di controllo dovrà seguire anch’essa le opportune
specifiche.
Per questi motivi e per altri, legati essenzialmente alle caratteristiche intrinseche del
linguaggio, è stato ritenuto come ottimale l’uso del linguaggio Visual Basic descritto
molto brevemente nella sezione precedente. La programmazione VB prevede, infatti, la
redazione di programmi dotati di un’interfaccia utente molto user friendly, basata
essenzialmente sul sistema di finestre utilizzate da Microsoft Windows. Questo
permette di progettare un’interfaccia utente modellata sia sulle abilità e le specifiche
provenienti lato utente, sia sulle diverse funzioni che il programma stesso dovrà essere
in grado di implementare. Per cominciare, diciamo che il programma di interfaccia,
chiamato B-Serial, si compone di due Form e di quattro Moduli. In VB il form è la
finestra principale dell’applicazione in cui possono essere inseriti elementi visuali come
112
pulsanti o caselle di testo, tramite i quali l’utente decide lo svolgersi del programma,
concezione che deriva dalla definizione di linguaggio orientato agli eventi propria del
VB. I moduli invece contengono di solito le definizioni di variabili, funzioni o classi
che vengono richiamate durante il codice scritto nel form.
Figura 5.2 Schermata principale dell'interfaccia utente
Il form principale si compone fondamentalmente di quattro tasti principali. Nell’ipotesi
progettuale più ampia, ogni tasto sarà associato facilmente al controllo di un diverso
attuatore domotico, realizzando in questo modo, un centro di controllo polifunzionale.
Anticipaimo che (nella seconda sezione si parlerà in modo più approfondito di questo
aspetto) l’host potrà essere equipaggiato con un sistema a touch screen o a comando
vocale per garantire una maggior accessibilità all’utente (già fornita per altro da
un’interfaccia a quattro “tastoni” come quella siffatta).
Per la programmazione si parte, come detto, dalla progettazione dell’interfaccia utente,
per poi dedicarsi alla scrittura vera e propria del codice. Dietro ogni tasto e controllo di
varia natura, c’è quindi il codice che realizza la funzionalità a cui il controllo stesso
corrisponde. La pressione del tasto uno (“luce”) deve corrispondere ad una serie di
azioni, dettate proprio dal relativo codice scritto dal programmatore. Il secondo Form,
ancora in fase di sviluppo, costituisce essenzialmente un setup necessario per stabilire la
113
connessione desiderata con il dispositivo Wi-Fi che costituisce il terminale domotico da
controllare. Questo form non è fondalmente destinato all’utente finale, che in una fase
più avanzata non si troverà costretto a settare le impostazioni necessarie alla
comunicazione che verranno caricate in automatico. In questa ancora iniziale fase di
sviluppo si è preferito piuttosto, prendere padronanza con le istruzioni necessarie al
corretto funzionamento della connessione, lasciando all’utente la libertà di cambiare le
impostazioni, così da testare l’efficienza e della comunicazione instaurata.
Figura 5.3 La schermata di configurazione
Concentriamoci adesso sull’analisi più specifica del programma di interfaccia realizzato
e sul codice che sostanzialmente lo compone.
In prima analisi, osservando in modo superficiale i form proposti, si può facilmente
notare come VB permetta di realizzare interfacce in puro stile Microsoft Windows,
dotate di tutti i tool corrispondenti. Il vantaggio di utilizzare un linguaggio di
programmazione del genere, è quello di poter disporre di Controlli già pronti, che
permettono di implementare funzionalità anche complesse, solo impostandone alcune
proprietà nel modo corretto, descritte per altro in modo esauriente in letteratura. Nello
specifico, quello che si intendeva realizzare tramite il software in esame, era la
possibilità di instaurare una connessione sia di tipo seriale (tramite porta COM) che di
tipo Wireless LAN (Wi-Fi). Ricordiamo, infatti, che l’idea di base è quella di portare a
114
compimento la progettazione di un sistema di controllo domotico wireless, capace di
salvaguardare le specifiche di portabilità e di semplicità di installazione.
A questo copo sono stati utilizzati fondamentalmente due controlli esistenti e
ampiamente funzionanti:
•
MSCOMM.OCX per la comunicazione seriale;
•
WinSock per la comunicazione LAN (e quindi anche WiFi).
5.3.1 MSCOMM
Con Visual Basic viene fornito un componente per la gestione della seriale, l'
MSCOMM.OCX.
L'MSCOMM dispone di diverse proprietà, di un solo evento ( OnComm() ) e nessun
metodo. Nell’applicazione trattata in particolare, MSCOMM è richiamato dal secondo
form, quando si setta la comunicazione seriale. In particolare, come evidenziato nella
figura seguente, al controllo Command3 nominato Set Serial corrisponde il richiamo del
controllo MSComm.
Figura 5.4 Particolare della schermata di configurazione della comunicazione seriale. In rosso I campi
destinati ai setting e il tasto di connessione.
115
'Imposto la porta di comunicazione
Me.MSComm1.CommPort =
CInt(Right(Me.cmb_port.List(Me.cmb_port.ListIndex),1))
'Creo la stringa di configurazione <speed>,n,8,1
cfgstr = Me.cmb_speed.List(Me.cmb_speed.ListIndex)
If chk_parity.Value = vbChecked Then
cfgstr = cfgstr & ",s"
Else
cfgstr = cfgstr & ",n"
End If
cfgstr = cfgstr & "," & cmb_data.List(cmb_data.ListIndex)
If chk_stop.Value = vbChecked Then
cfgstr = cfgstr & ",1"
Else
cfgstr = cfgstr & ",0"
End If
'Imposto la stringa di configurazione
Me.MSComm1.Settings = cfgstr
'Apro la porta
Me.MSComm1.PortOpen = True
Il codice si occupa prima di tutto di selezionare la porta Com sulla quale bisogna
instaurare la comunicazione. A questo scopo definiamo la proprietà Commport
dell’oggetto MSComm1 tramite il valore introdotto dall’utente nella combobox
corrispondente presente nel form considerato.
Figura 5.5 Box per la trasmissione di dati su seriale.
116
Dopo aver scelto la porta si settano le combobox relative al protocollo che si vuole
utilizzare (8n1), questi valori vengono presi dal codice e assegnati alle proprietà
corrispondenti dell’oggetto MSComm1. È possibile quindi aprire la porta COM
corrispondente impostando come True la proprietà PortOpen di MSComm, in questo
modo si richiede il permesso al sistema di utilizzare la porta scelta. Se la porta è
disponibile, il sistema operativo la assegnerà a noi, diversamente, se la porta è già
utilizzata da un altro processo, verrà generato un errore intercettabile con l'istruzione
ON ERROR. Per chiudere la porta e rilasciarne il controllo, è sufficiente impostare
PortOpen su False. Il programma di interfaccia a questo punto, se i settings immessi
sono corretti, permette la visualizzazione di un box di dialogo apposito per l’invio e la
ricezione dei dati su seriale.
Private Sub Command1_Click()
Dim chr As String
On Error GoTo errhdl
If InStr(1, Me.cmb_char.Text, "(") = 0 Then
chr = Me.cmb_char.Text & vbCrLf
Else
chr = Mid(Me.cmb_char.List(Me.cmb_char.ListIndex),
Len(Me.cmb_char.List(Me.cmb_char.ListIndex)) - 1, 1)
End If
Me.MSComm1.Output = chr
S_TX_out (chr)
message_out "Sent char on TX Line"
If txt_status(1).BackColor <> vbYellow Then
txt_status(1).BackColor =
vbYellow
Else txt_status(1).BackColor = vbGreen
Exit Sub
errhdl:
message_out "Critical error while sending"
End Sub
117
Il codice riportato viene richiamato in seguito alla pressione sul pulsante Send Char, che
invia il carattere selezionato nell’apposita combobox secondo le impostazioni decise
nello step precedente.
Per quanto riguarda invece la ricezione di caratteri, è necessario dire che il controllo
MSComm è asincrono, perciò è il controllo stesso che si occupa di informare il
programma di ciò che accade tramite il richiamo dell’evento OnComm() e
l’impostazione della proprietà CommEvent. Quando viene richiamato l’evento
OnComm, nella proprietà CommEvents è riportato l’evento accaduto, secondo un
codice che varia a seconda di quello che succede.
Private Sub MSComm1_OnComm()
Dim chr As String, connection As String
If Me.MSComm1.CommEvent = comEvReceive Then
chr = Me.MSComm1.Input
Me.txt_rxchrs.Text = Me.txt_rxchrs.Text & chr
connection = Switch(ConnectionType = 1, "Serial",
ConnectionType = 2, "WiFi")
frm_IO_panel.Text1.Text = "Received from " & connection & ": " & chr
End If
message_out "Received Char on Serial Port"
S_RX_out chr
If txt_status(2).BackColor <> vbYellow
Then txt_status(2).BackColor = vbYellow
Else txt_status(2).BackColor = vbGreen
End Sub
Nella subroutine relativa all’evento MSComm1_OnComm(), la proprietà CommEvent
viene utilizzata per caratterizzare il numero di caratteri ricevuti, che vengono poi
caricati nella variabile chr tramite la proprietà Input di MSComm.
In realtà la funzionalità di comunicazione su RS-232 viene utilizzata solo come test,
l’interfaccia infatti è visto soprattutto come software capace di improntare una
comunicazione su LAN, in particolare su WiFi.
118
5.3.2 WINSOCK
Questo controllo fornisce al programma realizzato tutte le funzionalità necessarie per
implementare una comunicazione su LAN secondo il protocollo TCP o UDP. Il primo
consente di creare e mantenere una connessione con un computer remoto. Utilizzando la
connessione, entrambi i computer possono inviare e ricevere dati. Il protocollo TCP è
un protocollo basato sulla connessione ed è analogo ad un telefono, in quanto l'utente
deve stabilire una connessione prima di poter procedere. Per quanto riguarda l’UDP è
un protocollo senza connessione. A differenza del TCP, non viene stabilita alcuna
connessione tra i computer e la transazione tra due computer è analoga al passaggio di
un messaggio che viene inviato da un computer all'altro, senza che venga stabilita una
connessione esplicita tra i due computer. La dimensione massima dei dati che è
possibile inviare in ciascuna trasmissione dipende della rete. Per creare applicazioni
client o server non è necessario conoscere in maniera approfondita il TCP o richiamare
API Winsock di basso livello (simili alle system call socket di Unix). Impostando le
proprietà e attivando i metodi del controllo (object oriented e event driven), è possibile
connettersi a un computer remoto e trasferire i dati in entrambe le direzioni. Il controllo
Winsock dispone di proprietà, di metodi e di eventi. Nel nostro programma, questo
controllo viene richiamato dalla sezione corrispondente alla comunicazione WiFi del
Form.
Figura 5.6 Comunicazione WiFi. Setting e box di comunicazione
119
Come nel caso precedente, vediamo che il form possiede una porzione composta da text
box destinate all’inserimento dei parametri necessari per la connessione. Alla pressione
nel tasto Connect verrà richiamato il controllo Winsock che, sfruttando i parametri
inseriti in precedenza, effettuerà la connessione.
wf_l_ip = Text1(0).Text
wf_r_ip = Text1(1).Text
wf_l_port = Text1(2).Text
wf_r_port = Text1(3).Text
'Parlo in TCP/IP al destination
Me.Winsock1.LocalPort = wf_l_port
Me.Winsock1.RemotePort = wf_r_port
Me.Winsock1.RemoteHost = wf_r_ip
Me.Winsock1.Protocol = sckTCPProtocol
Me.Winsock1.Connect Me.Winsock1.RemoteHost, Me.Winsock1.RemotePort
message_out "Waiting for connection response..."
La prima parte del codice imposta le variabili in corrispondenza delle caselle di testo,
che dovranno essere utilizzate per immettere i settings della connessione desiderata.
Nella seconda parte, i dati inseriti vengono assegnati alle proprietà corrispondenti del
controllo Winsock. Sono i valori assegnati alle proprietà che vengono utilizzati per
stabilire la connessione. In particolare le proprietà richieste sono:
•
LocalPort, che deve contenere il valore corrispondente alla porta messa a
disposizione dall’host per la comunicazione. Nel nostro caso la porta è la
numero 1470, valore di default del dispositivo EZL utilizzato per la conversione.
•
RemotePort, contiene il valore corrispondente della porta del remoto con il quale
si stabilisce la connessione. È preferibile scegliere tale valore coincidente con
quello della porta locale.
•
RemoteHost, contiene l’indirizzo IP della macchina remota, quella cioè con cui
si vuole stabilire la connessione. Nel nostro caso l’indirizzo è quello dell’EZL e
vale 10.1.0.1.
•
Protocol, sckTCPProtocol setta il controllo Winsock sul protocollo TCP.
•
120
Winsock1.Connect Me.Winsock1.RemoteHost, Me.Winsock1.RemotePort
Questa riga di codice comunica al conrollo Winsock di effettuare la connessione con il
RemoteHost sulla RemotePort.
La pressione sul pulsante Send Char richiama la funzione per l’invio del carattere
selezionato nella corrispondente Combo box. Vediamo come.
Private Sub Command6_Click()
Dim buffer As String
If InStr(1, Me.cmb_char_wifi.Text, "(", vbTextCompare) = 0 Then
buffer = Me.cmb_char_wifi.Text
Else
buffer =
Mid(Me.cmb_char_wifi.List(Me.cmb_char_wifi.ListIndex),
Len(Me.cmb_char_wifi.List(Me.cmb_char_wifi.ListIndex)) - 1, 1)
End If
Me.Winsock1.SendData buffer
If txt_status(5).BackColor <> vbYellow
Then txt_status(5).BackColor = vbYellow
Else txt_status(5).BackColor = vbGreen
Exit Sub
I dati da inviare vengono caricati nella variabile buffer e tramite il metodo SendData
vengono inviati al ricevitore che in questo particolare caso è l’EZL, considerato come il
Server, mentre l’Host è in realtà il Client. In una trasmissione Client/Server infatti uno
dei due dispositivi richiede la connessione (il client/host appunto) mentre l’altro
terminale rimane in ascolto, in attesa della richiesta (il server/EZL).
L’interfaccia, provvedendo come detto ad una comunicazione bidirezionale con il
dispositivo di controllo domotico, sarà in grado anche di ricevere dati via WiFi LAN.
Anche questa funzionalità viene rimandata al controllo Winsock.
121
Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)
Dim buffer As String, connection As String
Me.Winsock1.GetData buffer, vbString
Me.txt_rxchars_wifi.Text = Me.txt_rxchars_wifi & buffer
If txt_status(6).BackColor <> vbYellow
Then txt_status(6).BackColor = vbYellow
Else txt_status(6).BackColor = vbGreen
connection = Switch(ConnectionType = 1, "Serial",
ConnectionType = 2,"WiFi")
If transition = False Then
frm_IO_panel.Text1.Text = "Received from " & connection
& ": " & buffer
End If
In questo caso utilizziamo il metodo GetData tramite il quale vengono recepiti i dati
messi nella variabile buffer, il contenuto della quale è visibile nella casello di testo
relativa ai dati in arrivo da remoto.
Sia la funzione di trasmissione che di ricezione possono essere controllate dalla
schermata a tasti implementata dal primo form. L’utente si troverà davanti questa
schermata durante il controllo dei diversi dispositivi. A questo scopo la pressione del
tasto uno richiama in realtà la stessa funzione implementata dal pulsante Send Char
presente sul form di configurazione. L’utente viene in questo modo svincolato dalle
procedure di setup che, in una fase futura, potrebbe essere resa automatica. Traccia
dell’avvenuta ricezione viene invece riportata nella barra di testo, presente anch’essa nel
form principale.
122
Figura 5.7 Particolare dell'interfaccia a tasti. Il tasto invia il segnale responsabile dell'azionamento. Nella
casella di testo compare il segnale di ritorno.
Quelle riportate in questo capitolo, rapresentano le sezioni di codice fondamentali che
garantiscono le funzionalità richieste al nostro programma di interfaccia, riportato per
intero in appendice. La struttura del programma, permette all’utente di interagire con i
controlli posizionati nell’abitazione, tramite la pressione (o come si vedrà in seguito il
comando vocale) dei quattro tasti realizzati nel form principale. È, infatti, questa la
schermata proposta all’utente all’avvio del software, accompagnata da una
comunicazione vocale che comunica all’utente che l’interfaccia è pronta.
'Inizializzo la voce
Call SetVoice
Saysentence "Pronto", 0
Con queste righe di codice il programma richiama la Sub SetVoice, presente in uno dei
moduli inclusi nel progetto, con la quale viene caricata la funzionalità vocale che servirà
a fornire il feedback interpretabile all’utente. La modalità vocale viene infatti utilizzata
dal programma di interfaccia per comunicare al soggetto l’avvenuto azionamento
dell’attuatore. Infatti, mentre da un lato il software invia messaggi al circuito di
controllo comandandone l’attivazione, dall’altro riceve dallo stesso circuito messaggi
123
legati alle azioni svolte dall’applicativo. Il software è programmato in modo tale da
inviare all’utente un messaggio vocale nel momento in cui riceve in ingresso
comunicazione WiFi dal convertitore EZL. Riportiamo di seguito il codice che realizza
questa funzione.
Private Sub Text1_Change()
If InStr(1, Me.Text1.Text, "-able", vbTextCompare) > 0
Then
transition = True
Saysentence "Luce accesa", 0
End If
End Sub
Il microcontrollore è programmato (vedi il capitolo relativo alla realizzazione del
firmware) in modo tale da inviare il messaggio B-able nel momento in cui riceve il
feedback adeguato dal circuito appositamente realizzato (il circuito di feedback
appunto). In questo modo il circuito di controllo è in grado di fornire segnalazione
dell’avvenuta attivazione dell’attuatore che controlla. Una parte del codice costituente il
programma di interfaccia è stata creata proprio al fine di intercettare questo segnale e di
tradurlo in un input vocale per l’utente, realizzando quello switching sensoriale che
rappresenta uno dei tratti innovativi del seguente lavoro.
Nel caso specifico, l’utente vuole comandare l’accensione di un gruppo di luci. Il
sistema ausilio composto di interfaccia, circuito a microcontrollore e attuatore (descritto
nella seconda sezione) gli permette di controllare facilmente l’illuminazione. In più,
l’accensione delle luci provoca la nascita di un segnale di ritorno che, tramite il
microcontrollore, sarà inviato all’host e intercettato dall’interfaccia. Quest’ultima
provvederà quindi a comunicare (in questo caso vocalmente) all’utente l’avvenuta
attivazione del sistema, garantendogli lo switching sensoriale che “aggirerà” le sue
disabilità.
124
II SEZIONE – L’APPLICAZIONE
Il lato attuatore
La sezione precedente ha analizzato soprattutto quella parte hardware, basata
principalmente sul microcontrollore della Microchip, che realizza il cosiddetto circuito
di controllo. La problematica presa in considerazione, era quella di realizzare un sistema
ausilio che permettesse ad un utente disabile di interagire agevolmente con dispositivi
domotici generici, posizionati all’interno dell’abitazione, ricevendo dagli stessi gli
opportuni segnali di feedback, commisurati alle proprie abilità residue, sia motorie che
sensoriali. Analizzato il problema, si è passati alla determinazione degli opportuni
vincoli, tradotti nelle specifiche ingegneristiche seguite durante la realizzazione del
progetto. Il circuito di controllo implementato quindi, costituisce una centralina
intelligente che permette il controllo remoto da parte dell’utente, che deve solamente
impartire i comandi desiderati alla Power Station, rappresentata, come detto, dall’host
del sistema, improntato tramite software realizzati ad hoc che ne massimizzano
l’accessibilità.
A questo punto, il lavoro procede occupandosi degli aspetti strettamente connessi al lato
attuatore vero e proprio. Nella presente sezione, pertanto, partiremo descrivendo lo stato
dell’arte della tecnologia demotica, cercando di individuare quali sono le soluzioni
125
dedicate propriamente all’utenza disabile. Una volta inquadrato il mercato pertinente, ci
si occuperà di descrivere possibili soluzioni realizzabili tramite il sistema di ausilio
realizzato, per poi descriverne e prototipizzarne una specifica, che sottolineerà tutte le
funzioni implementate dal sistema.
Figura 1- Il Sistema Ausilio. Schema di principio
126
6. DOMOTICA: LO STATO DELL’ARTE
6.1 La Domotica
Alla domanda cos’è la domotica si inizia di solito riferendosi al neologismo derivato da
domus- casa e informatique- informatica, vale a dire casa automatizzata o più
propriamente Casa Intelligente.
Ma cos’è in realtà?
In realtà la domotica è la scienza interdisciplinare che si occupa dello studio delle
tecnologie atte a migliorare la qualità della vita nella casa e più in generale negli
ambienti antropizzati[20]. La domotica si pone l’obiettivo di integrare, cioè far dialogare,
le tecnologie dell'impiantistica tradizionale già presenti negli edifici, con quelle
innovative, al fine di ottenere nuove e moderne funzionalità. Questa nuova scienza trova
il suo scopo nel migliorare la qualità dell'abitare e vivere nell'edificio. L'edificio si
trasforma in un ambiente nel quale è possibile vivere o lavorare efficientemente,
controllare i livelli di benessere e di salute, garantire praticità e sicurezza, risparmiare
energia, rispettare la natura. Ad un livello superiore si parla di building automation o
automazione degli edifici.
L'integrazione rappresenta la condivisione dell'informazione riducendo o eliminando
l'isolamento dei vari impianti installati in un edificio, riorganizzando la loro visione
127
attraverso un unico sistema impiantistico multifunzione in grado di controllare,
coordinare e comandare le singole funzioni lasciando ad ognuno la propria competenza
e responsabilità. L'edificio intelligente, con il supporto delle nuove tecnologie, permette
la gestione coordinata, integrata e computerizzata degli impianti tecnologici
(climatizzazione, distribuzione acqua, gas ed energia, impianti di sicurezza), delle reti
informatiche e delle reti di comunicazione, allo scopo di migliorare la flessibilità di
gestione, il comfort, la sicurezza, il risparmio energetico degli immobili e per migliorare
la qualità dell'abitare e del lavorare all'interno degli edifici.
La casa intelligente può essere controllata dall'utilizzatore tramite opportune interfacce
utente (come pulsanti, telecomandi, touch screen, tastiere, riconoscimento vocale), che
realizzano il contatto (invio di comandi e ricezione di informazioni) con il sistema
intelligente di controllo, basato su un'unità computerizzata centrale (l’host), oppure su
un sistema a intelligenza distribuita (o su una combinazione delle due scuole di
pensiero). I diversi componenti del sistema sono connessi tra di loro e con il sistema di
controllo tramite vari tipi di interconnessione (ad esempio rete locale, onde radio, BUS
dedicato, ecc.).
Vedremo di seguito come viene organizzato e come è composto al giorno d’oggi un
sistema di tipo domotico.
Il sistema di controllo centralizzato, oppure l'insieme delle periferiche in un sistema ad
intelligenza distribuita, provvede a svolgere i comandi impartiti dall'utente (ad esempio
accensione luce cucina, oppure apertura tapparella sala), a monitorare continuamente i
parametri ambientali (come allagamento oppure presenza di gas), a gestire in maniera
autonoma alcune regolazioni (ad esempio temperatura) e a generare eventuali
segnalazioni all'utente o ai servizi di teleassistenza.
Un sistema domotico si completa, di solito, attraverso uno o più sistemi di
comunicazione con il mondo esterno (ad esempio messaggi telefonici preregistrati,
SMS, generazione automatica di pagine web o e-mail) per permetterne il controllo e la
visualizzazione dello stato anche da remoto. Sistemi comunicativi di questo tipo,
chiamati gateway o residential gateway svolgono la funzione di avanzati router,
permettono la connessione di tutta la rete domestica al mondo esterno, e quindi alle reti
di pubblico dominio.
Le informazioni vengono raccolte dal campo da dispositivi chiamati sensori. Rientrano
in questa categoria quelli che riescono a raccogliere eventi, informazioni e realtà dal
128
campo e che, quasi sempre, presuppongono il successivo verificarsi di un'azione. Un
pulsante che accende una luce è un sensore che raccoglie la volontà “voglio accendere
la luce”.Una sonda di temperatura è un sensore che informa sulla temperatura rilevata in
un determinato ambient,e che può far scaturire il mantenimento o la variazione del
comportamento dell'impianto termotecnico attivo in quel momento; un rilevatore di
presenza dell'antifurto, informa l'edificio che c'è una persona in un determinato
ambiente che, come avviene normalmente ad impianto “non inserito”, può essere
ignorato; in alternativa invece può attivare l’accensione di luci, impianti termotecnici o
semplicemente far memorizzare l'evento per successive elaborazioni.
Le “azioni” vengono effettuate invece dagli attuatori. A seguito di un evento registrato
da un sensore, l'attuatore hai il compito di svolgere l'azione. Per esempio a seguito della
pressione di un pulsante (evento) un dispositivo d'ingresso (sensore) raccoglie
l'informazione, un dispositivo d'uscita (attuatore) accende la luce (azione).
La separazione delle attuazioni dalle informazioni porta l'impiantistica ad una
evoluzione. Non si parla più di circuito fisico, ma di circuito logico.
Figura 1.1 Collegamento tradizionale e interposizione del circuito di controllo
129
In un impianto elettrico tradizionale, esiste un circuito fisico, la linea di potenza, che
collega il pulsante (o interruttore, deviatore, invertitore) direttamente al carico (per
esempio un corpo illuminante). Per poter agire su quel carico è necessario collegare a
quel circuito fisico, tutti i suoi dispositivi di comando. È facile intuire che ogni
variazione, modifica o estensione delle funzionalità legate a quel carico comportano una
modifica del circuito fisico e del cablaggio. In un impianto integrato abbiamo invece un
circuito logico. Tutti i dispositivi (sensori, attuatori) sono collegati tra di loro attraverso
un mezzo trasmissivo, il cui scopo è quello di trasmettere informazioni da un
dispositivo ad una altro, inoltre agli attuatori è collegata la linea di potenza, dovendo
agire sui dei carichi; l'intelligenza può essere collocata all'interno dei dispositivi o in
un'unità autonoma che li collega e gestisce entrambi. Il circuito logico, fa si che la
relazione che deve esistere tra un evento e la sua azione corrispondente non sia più
vincolata dal cablaggio fisico esistente tra di due dispositivi, ma dalle informazioni che i
dispositivi stessi si scambiano. Nei dispositivi tradizionali le funzioni di comando e di
attuazione generalmente coesistono nello stesso dispositivo in modo inscindibile, come
nel caso dell'interruttore. I dispositivi di un sistema integrato, al contrario, tenendo
separate le due funzioni si guadagna in funzionalità e modularità.
I diversi moduli possono essere organizzati secondo diverse topologie, cioè secondo
diverse configurazioni di collegamenti tra i nodi della rete. Esistono diverse topologie e
la scelta di quella da adottare è legata al conseguimento di alcuni obiettivi fondamentali:
•
Massimizzare l'affidabilità della rete: questo significa trovare una strada
alternativa tra due dispositivi quando la strada normalmente percorsa viene
interrotta a causa di malfunzionamenti; inoltre significa buona qualità della
trasmissione, ossia il più basso numero di errori possibile.
•
Massimizzare il rendimento complessivo della rete, ossia minimizzare i tempi di
risposta. Il rendimento si può misurare in transizioni elaborate nell'unità di
tempo.
•
Minimizzare i costi di rete, facendo in modo per esempio, che il numero
complessivo delle linee sia minimo.
Tenendo conto di questi obiettivi, le configurazioni possibili possono assumere le
seguenti forme.
130
Topologia a stella
La configurazione a stella partendo da un centro raggiunge ogni punto periferico con un
collegamento diretto. Agendo quindi al centro è possibile modificare funzioni e
collegamenti. Lo schema è il seguente:
Figura 1.2 Configurazione a stella
Nella topologia a stella, tutte le comunicazioni passano attraverso il punto centrale di
connessione che può essere sia passivo che attivo. Questo tipo di topologia semplifica la
rete perchè il punto centrale può controllare sia il traffico che i nodi, quindi
l'individuazione dei problemi è semplificata. La topologia a stella inoltre può emulare la
topologia a bus e mostra la sua flessibilità al crescere della rete, essendo comodo farla
crescere o farla evolvere ad una struttura ad albero.
I vantaggi di una topologia a stella sono:
•
alte prestazioni,
•
facilità di controllo,
•
il fuori uso di una stazione non influenza la rete.
Gli svantaggi sono:
•
l'affidabilità è legata al nodo centrale.
•
Se il mezzo trasmissivo è il cavo, ciò implica la necessità di utilizzarne molto,
ma soprattutto anche un maggior costo per la posa del cavo stesso.
131
Topologia ad albero
Questo tipo di configurazione può essere rappresentata graficamente nel seguente
modo:
Figura 1.3 Configurazione ad albero
Può essere considerata l'evoluzione della struttura a stella, ovvero a “stella di stelle”.
Presenta degli indubbi vantaggi, quali la semplificazione del percorso (esiste un solo
itinerario tra due nodi) e ne contiene quindi i costi di cablaggio.
Topologia ad anello
Nella topologia ad anello, tutte le stazioni sono collegate tra loro tramite linee punto a
punto in una caratteristica configurazione circolare, chiusa su stessa.
Figura 1.4 Configurazione ad anello
La trasmissione avviene generalmente in unico senso, ad esempio quello antiorario.
Tutte i nodi prendono parte alla trasmissione: quando una stazione invia sulla linea il
proprio pacchetto, questo percorre l'intero anello: ciascuna stazione riceve il pacchetto,
132
lo memorizza, lo rigenera e lo ritrasmette sulla linea successiva. Grazie alla
rigenerazione continua del segnale, operata dalle singole stazioni, l'anello può anche
avere un'elevata estensione. Al contrario, i limiti di estensione riguardano la distanza
massima tra nodo e nodo. Questa soluzione si rivela ottima se vengono usate le fibre
ottiche. Il numero di stazioni può variare da poche decine fino a migliaia di unità.
Gli svantaggi fondamentali di questa soluzione sono i seguenti:
•
la lunghezza complessiva del cavo non è minimizzata,
•
l'affidabilità dell'intero sistema è critica,
•
l'inserimento di un'eventuale nuova stazione rende necessario interrompere il
funzionamento dell' intera struttura.
I problemi principali sono proprio gli ultimi due, ossia l'affidabilità e l'inserimento di
nuove stazioni.
Topologia Lineare (BUS).
Nella topologia a bus lineare, c'è un unico cavo che si estende su tutta l'area in cui sono
situati i nodi:
Figura 1.5 Configurazione lineare
I dati viaggiano sul cavo e sono leggibili da parte di tutti. Quindi, la trasmissione di una
stazione viene ricevuta da tutte le altre, nonostante possa essere in realtà diretta ad una
stazione destinataria.
I maggiori vantaggi consistono nella semplicità, nei bassi costi e nell'affidabilità di
questa topologia. Non solo, ma è evidente che il guasto di una qualsiasi stazione non
provoca la disattivazione dell'intera rete, dato che le stazioni sono passive quando non
trasmettono, al contrario di quanto succede nella topologia ad anello, dove ogni stazione
deve ricevere, rigenerare e ritrasmettere ogni pacchetto. Oltre ad aggiungere nuove
stazioni, si può pensare di collegare varie dorsali, dette segmenti. I principali
inconvenienti di una rete lineare sono:
133
•
i potenziali problemi di prestazioni dovute all' utilizzo di un solo cavo per tutte
le stazioni;
•
eventuale interruzione del cavo mette fuori uso la rete;
•
difficoltà nell' individuare i malfunzionamenti;
•
distanza massima tra le stazioni.
Per quanto riguarda i tipi di architettura utilizzabile, si distinguono in base a come si
vuole indicare la struttura logica, cioè il modo in cui sono raggruppati, collegati e,
fondamentalmente controllati i vari dispositivi che compongono l'impianto. La
classificazione avviene quindi in funzione della localizzazione della capacità
decisionale del sistema. Si distinguono tre tipi di architetture:
•
Architettura centralizzata.
•
Architettura distribuita.
•
Architettura mista.
Nell'architettura centralizzata esiste un'unica unità di decisione anche suddivisa in più
unità intelligenti, con diversi livelli gerarchici ed eventualmente distribuite fisicamente.
I dispositivi distribuiti in campo, pur potendo essere dotati di intelligenza locale non
sono in grado di prendere le decisioni sul da farsi, rimandandole comunque sempre
all'unità centrale. I messaggi provenienti dai sensori/comandi sono quindi sempre
elaborati dall'unità intelligente centrale che, esaminate tutte le informazioni a sua
disposizione, decide cosa, in quale modo e in quali tempi scatenare gli eventi
corrispondenti, necessari e programmati. È quindi nell'unità centrale che risiede
l'intelligenza per elaborare e gestire le informazioni che viaggiano sul mezzo
trasmissivo. Generalmente quindi si semplifica la fase di programmazione dei
dispositivi, perchè basta configurare l'elemento master per il funzionamento dell'intero
sistema.
Nell'architettura distribuita (utilizzata quindi nel sistema ausilio realizzato) tutti i
dispositivi sono intelligenti, dispongono direttamente del programma che loro compete
e possono quindi elaborare le informazioni che viaggiano sul mezzo trasmissivo: essi
sono in grado di riconoscere se l'informazione è indirizzata a loro e decidere ed agire di
conseguenza. L'intelligenza dell'elaborazione delle informazioni non è concentrata, o
134
meglio centralizzata in un dispositivo master, ma al contrario è distribuita nei
dispositivi in campo. In un'architettura distribuita, i dispositivi vengono detti
intelligenti. Perchè un componente diventi veramente intelligente, oltre all'hardware di
cui è dotato, bisogna fornirgli i parametri o la programmazione opportuna. Per
realizzarla occorre:
•
definire il nome univoco del dispositivo: ossia è necessario fornire al
dispositivo un indirizzo (un nome e un cognome) unico in tutto il sistema.
Questa operazione è molto importante perchè identifica univocamente il
componente intelligente all'interno della rete.
•
definire quale funzione deve realizzare e secondo quali modalità. Per esempio
prendendo un pulsante dell'impianto elettrico che deve accendere un corpo
illuminante, se abbinato ad una pressione normale e breve ne realizza
l'accensione o lo spegnimento; se invece si abbina ad una pressione lunga (5-10
secondi), può attivare qualunque altro evento da spegnimento generale, scenario
notte-giorno, irrigazione giardino o quanto definito dalla fantasia o dalle
necessità. Lo stesso componente è quindi in grado di realizzare più funzioni a
seconda della programmazione che gli viene assegnata. Lo stesso componente
può essere utilizzato indifferentemente come pulsante per il campanello, oppure
come trimmer per variare l' intensità luminosa, oppure come comando passopasso per le tapparelle. Dal punto di vista del committente tutti gli interruttori
sono uguali; dal punto di vista impiantistico invece un interruttore si differenzia
da un invertitore o da un deviatore per i morsetti che si trovano sul retro del
dispositivo, per i cavi che è necessario collegare e per le funzioni che si possono
realizzare (accensione o spegnimento di un carico da uno, due o tre punti
diversi). Se gli stessi prodotti vengono dotati di intelligenza, la differenza sulle
modalità di funzionamento è definita logicamente e realizzata a livello software
o direttamente a livello hardware e modificabile in ogni momento. Il dispositivo
intelligente è sempre lo stesso dal punto di vista fisico, ma è tuttavia in grado di
assolvere a svariate funzioni, purché sia parametrizzato o programmato
opportunamente.
•
Definire con quale componente deve realizzare la funzione specifica (per
esempio: il pulsante precedente deve sapere che per accendere una determinata
luce deve comandare un determinato terminale di uscita mentre per realizzare la
135
seconda funzione deve dialogare con uno o più altri attuatori). Il sistema deve
necessariamente dialogare con tutti i sensori e gli attuatori e conoscere tutte le
informazioni. Quest'ultimo passaggio può essere visto come il cablaggio, a
livello logico, del sistema che si va a realizzare.
Nella soluzione mista invece, abbiamo un cablaggio principale a livello edificio con
tipologia di architettura distribuita; si raggiunge una dimensione più piccola chiamata
ambiente. L'interno dell'ambiente invece è realizzato con architettura centralizzata e
collegamento a stella dei dispositivi di campo. Oggi questa scelta di architettura mista
viene sempre più utilizzata. Non avendo raggiunto ancora una standardizzazione dei
protocolli di comunicazione si tende a realizzare la dorsale di edificio con una
tecnologia consortile (KNX o LON), standard TCP-IP (Cablaggio strutturato) o dorsale
proprietaria per andare poi sul campo a stella con protocolli diversi a seconda degli
impianti o delle tecnologie utilizzate. L'integrazione viene quindi realizzata attraverso le
interfacce che permettono di mettere insieme dispositivi con protocolli di
comunicazione diversi.
Il protocollo di comunicazione è un elemento distintivo di ogni rete, incluse quelle
domestiche, dal momento che rappresenta il linguaggio comune tra diversi dispositivi e
sistemi di supervisione. È al tempo stesso discriminante nelle scelte progettuali e
installative, sia per gli edifici sia per l'automazione domestica in genere, e la sua
tipologia (proprietaria o aperta, standardizzata o meno) può determinare la
caratterizzazione e il successo di un installazione.
Molte reti in ambito domotico utilizzano un protocollo che rientra nel modello ISO/OSI
(open system interconnession - interconnessione di sistemi aperti), valido per tutte le
reti locali, ma utilizzabile anche per reti estese, utile per definire la connessione e
l'accesso di ogni dispositivo alla rete, ovvero le precise modalità con cui l'informazione
fornita dal singolo componente o ad esso inviata, viene codificata, trasformata e
istradata sul supporto fisico che costituisce la rete.
136
Questo processo viene descritto secondo una struttura a 7 livelli:
1. Mezzo fisico
2. Collegamento del dato alla rete (Link)
3. Instradamento
4. Trasporto
5. Sessione
6. Presentazione
7. Applicazione
Per i protocolli che si adeguano a questo schema è assicurata la possibilità di
interconnessione, cioè lo scambio di informazioni fra livelli analoghi, grazie all'impiego
di opportuni dispositivi detti ponti o gateway. Una scelta possibile per le reti dedicate è
quella di tralasciare alcuni di questi livelli, generalmente dal 3 al 6, semplificando così
sia le modalità di codifica dei messaggi, sia il relativo costo di implementazione. Ciò
avviene anche per molte delle reti utilizzate in ambito domestico.
I protocolli possono essere così distinti:
•
I protocolli consortili sono il frutto di regole comuni che consorzi di aziende
produttrici di dispositivi ed erogatori di servizio si sono date, al fine di
immettere sul mercato dispositivi e soluzioni che parlino una lingua comune. Li
troviamo utilizzati in architetture di rete distribuita con i vari dispositivi che
sono dotati di intelligenza, per la gestione di applicazioni di networking ed
applicative. Ogni dispositivo, prima di essere messo sul mercato col marchio
del consorzio, dovendo superare dei test di compatibilità, deve essere certificato
(dal Consorzio stesso, da Ente esterno abilitato o dall'azienda stessa). Ciò
fornisce la certezza che il dispositivo di un determinato produttore può
convivere senza problemi con dispositivi certificati di altri produttori. I
principali consorzi del settore presenti in Italia ed in Europa sono:
ƒ
Konnex (http://www.konnex.it)
ƒ
LonWork (http://www.lonmark.com).
ƒ
TCP-IP è il protocollo di internet ed è usato tipicamente in tutte le applicazioni
della tecnologia delle comunicazioni (ICT Information & Communication
Technology). Generalmente in ambito home e building automation, questo
protocollo è utilizzato da apparati attivi cioè alimentati direttamente dalla
tensione di rete. Gli apparati disponibili, oltre a tutti quelli direttamente legati al
137
mondo reti, dell'informatica e di internet, sono in rapida crescita e spaziano su
una varietà di dispositivi come telecamere e telefoni. Come mezzo trasmissivo
esso utilizza il cablaggio strutturato descritto in precedenza.
•
I protocolli proprietari sono quelli implementati direttamente da singoli
produttori e fornitori per introdurre soluzioni anche estremamente performanti
in termini prestazionali, funzionali o economiche. Va preso atto della loro
considerevole diffusione e delle caratteristiche spesso considerevoli di novità,
innovazione e prestazioni che molto spesso riescono ad offrire. Molti di questi
protocolli, per diffusione sul mercato, hanno raggiunto livelli di standard de
facto. I sistemi che li utilizzano poi possono inglobarne uno o più per poter
offrire una flessibilità anche molto simile a quella dei protocolli descritti prima.
Il vincolo all'acquisto da un unico produttore può essere estremamente variabile
da soluzione a soluzione ed arrivare ad essere anche estremamente contenuto,
ovvero l'utente ha realmente a disposizione una soluzione aperta che gli
permettere di scegliere dispositivi messi sul mercato da diversi costruttori,
secondo quella che ritiene essere la soluzione migliore per il suo specifico
problema di home o building automation. In tutti i casi quindi, si deve prestare
una certa attenzione alla scelta della soluzione tecnologica, considerandone
attentamente sia i vantaggi sia gli svantaggi e cercando la salvaguardia delle
esigenze del progetto dell'utente a cui è destinata.
•
Altri protocolli che possiamo citare sono:
•
il protocollo IRDA, protocollo per la connessione a Raggi Infrarossi, usatissimo
dai telecomandi, il cui limite sostanziale è la distanza utile per la connessione e
la necessità di visibilità ottica dei dispositivi che devono comunicare.
•
Il protocollo Bluetooth: è un protocollo per la connessione senza fili di
dispositivi elettronici diversi, come stampanti, computers, telefoni cellulari,
palmari. La trasmissione consente di raggiungere un massimo di 1 Mbps e la
potenza in gioco pari a 1 milliwatt permette un raggio operativo stimato di 10
metri.
138
•
Il protocollo UPnP (Universal Plug and Play) si basa su protocolli Web
standard per permette a un’ampia gamma di dispositivi di riconoscersi e di
comunicare direttamente tra di loro o attraverso apparecchiature intermedie.
•
Il protocollo Jini è proposto come uno standard industriale aperto che vuole
permettere l’esistenza di un ampio numero di dispositivi consumer
interoperabili. Jini propone un modello completamente nuovo di networking nel
quale non si parla più di computer che eseguono programmi, ma di oggetti che
forniscono dei servizi e questi oggetti possono essere periferiche intelligenti ed
elettrodomestici.
Oggi sul mercato esistono numerosi dispositivi che permettono la realizzazione di
impianti domotici. Questi possono essere più o meno specializzati nello svolgere
determinate funzioni. Per meglio descriverli è possibile fare un raggruppamento in base
alla loro funzionalità, distinguiamo quindi:
•
dispositivi di comando e sensori
•
dispositivi d'uscita
•
dispositivi di controllo e gestione
•
dispositivi di sistema
•
le interfacce
Dispositivi di comando e sensori
I sensori, sono quei dispositivi che hanno il compito di rilevare o misurare delle
grandezze fisiche dell'ambiente in cui si trovano. I dispositivi di comando sono
particolari sensori in quanto raccolgono informazioni dal campo. Questi possono essere:
•
dispositivi di comando tradizionali
•
dispositivi di comando intelligenti
Nel primo caso si comprendono tutti quei dispositivi commerciali che non stati
appositamente progettati per i sistemi d'automazione, ma che possono essere utilizzati
se interfacciati con opportuni dispositivi d'ingresso. Nel secondo caso invece,
comprendono tutti quei dispositivi appositamente studiati e progettati per essere
integrati in un sistema domotico.
Per quanto riguarda invece i sensori veri e propri (quelli che rilevano misure fisiche dal
campo) questi possono essere dedicati ad una particolare funzione e quindi avere un
139
determinato compito, come ad esempio misurare la temperatura o valutare la luminosità
ambientale, oppure contenere più apparati sensoriali. Come per i dispositivi di comando
anche in questo caso si può fare la distinzione tra sensori tradizionali, che hanno
bisogno di un ingresso o dispositivo d'ingresso per diventare parte di un impianto
domotico, oppure sensori intelligenti già dotati di interfaccie particolari e
opportunamente studiati e progettati per poter colloquiare all'interno di una rete, quindi
essere un nodo di un sistema integrato. I sensori rappresentano un elemento
fondamentale in un sistema domotico, perchè raccolgono le informazioni dal campo e le
trasformano in dati che verranno gestiti e a seguito dei quali, verranno svolte azioni da
parte dei moduli d'uscita.
Vediamo ora alcune tipologie di sensori:
- cellula fotoelettrica
- contatti magnetici
- contatto a fune
- rilevatore di presenza
- sensore volumetrico
- sensore rottura vetro
- sensore temperatura
- sensore acqua
- sensore fumo
- sensore gas
- sensore crepuscolare
- sensore di luce
6.1.1 Dispositivi d’uscita
I dispositivi d'uscita sono dispositivi a cui sono collegati direttamente o indirettamente, i
carichi elettrici. La differenza principale è data dalla modalità di collegamento al carico
elettrico. Inoltre altre differenze sono costituita da:
- numero e tipologia di carichi elettrici collegabili(induttivi, resistivi,…)
- carico massimo collegabile
- forma del dispositivo
- funzionalità o parametrizzazione possibile.
140
Per quanto riguarda invece la modalità di collegamento possiamo distinguere:
- uscire binarie: attiva o disattiva un carico attraverso un relais o circuito equivalente
- uscita dimmer: secondo i modelli regola la tensione o corrente, per regolare il carico
direttamente
o attraverso un regolatore elettronico
- uscita analogica: fornisce una corrente o tensione variabile, generalmente utilizzata per
comandare apparecchiature non intelligenti
6.1.2 Sistemi di controllo e gestione
Sono dispositivi di gestione del sistema quelli che, per esempio, intervengono sul
sistema ad intervalli regolari o a scadenze precise per attivare o disattivare utenze,
oppure
consentono
di
effettuare
particolari
e
complesse
operazioni
di
comando/attuazione. Nella sezione controllo invece, possiamo includere quei dispositivi
che monitorano ed eventualmente agiscono su utenze/carichi per esempio in caso di un
sovraccarico. L'integrazione degli impianti, a seguito della gestione delle informazioni,
sia in maniera centralizzata, distribuita o mista, permette la gestione e realizzazione di
funzioni anche complesse. Queste vengono identificate spesso con il termine scenari.
Gli scenari possono essere semplici, come per esempio lo spegnimento di tutte o parte
delle luci, oppure più complessi come per esempio la chiusura di un edificio (chiusura
luci, movimentazioni, inserimento sistema sicurezza,…). In generale definiamo scenario
un qualsiasi insieme di più azioni, di impianti differenti per il raggiungimento di uno
stato in cui si deve configurare l'edificio in determinate occasioni, situazioni oppure a
comando. La realizzazione di scenari, generalmente è abbastanza semplificata. A volte
esistono apparecchiature dedicate, altre volte invece è l'insieme della parametrizzazione
dei dispositivi che ne permette la realizzazione. In un'architettura distribuita
generalmente è possibile ottenere degli scenari semplici, attraverso la parametrizzazione
dei dispositivi, mentre per scenari più complessi è necessario l'uso di dispositivi fisici
che memorizzino i dati salienti (p.e. varie combinazioni e successione di eventi,
intervalli temporali e condizioni che devono verificarsi) per realizzarli. In un'architettura
centralizzata, invece generalmente la gestione degli scenari avviene tramite un
opportuna programmazione della centrale di controllo, non sono quindi necessari
dispositivi aggiuntivi per realizzarli.
141
6.1.3 Dispositivi di sistema
Alimentatore:
L'alimentatore è un dispositivo generalmente indispensabile e serve per fornire energia a
tutti i dispositivi che necessitano di potenza elettrica. I vari sistemi presenti attualmente
sul mercato alimentano i dispositivi con tensioni comprese tra 12V ed i 30V; tutte le
tensioni in gioco sono comunque sempre in sicurezza (SELV-Safety Extra Low
Voltage), ovvero nei circuiti è assicurata la protezione contro i contatti diretti in
ambienti ordinari se la tensione non supera i 25Vac ed i 60Vcc. La sicurezza PELV
garantisce la protezione dei circuiti contro i contatti diretti in ambienti ordinari per
tensioni non superiori ai 6Vca ed ai 15Vcc. L'alimentatore viene posto all'interno del
quadro generale. Il numero di alimentatori all'interno di un impianto domotico dipende
dalle specifiche tecniche e dai limiti imposti dalle case costruttrici. Generalmente questi
limiti dipendono dal numero di dispositivi presenti su una medesima linea e dalla
distanza massima tollerabile del dispositivo dall'alimentatore.
Dispositivi di accoppiamento:
Servono per cambiare mezzo trasmissivo all'interno della stessa rete e si utilizzano dei
dispositivi chiamati router. Oppure per integrare due linee dedicate a funzioni diverse,
per
esempio
automazione
con
antiintrusione,
si
utilizzano
dispositivi
di
interfacciamento per poter far dialogare i due sistemi.
Un altro e tipico dispositivo appartenente a questa categoria è l'interfaccia del sistema
domotico con il PC; questa può avvenire per esempio tramite una porta seriale ( RS232,
RS485) oppure porta USB.
6.1.4 Interfacce e residential gateway
L'interfaccia con gli utenti finali rappresenta uno degli aspetti fondamentali dei sistemi
domotici, infatti è lo strumento attraverso il quale l'abitante o l'utente dell'edificio
interagisce col sistema. I requisiti dell'interfaccia fra l'edificio ed il suo abitante-
142
utilizzatore sono dettati da ragioni di carattere tecnico, ma anche e soprattutto da
esigenze di funzionalità e, soprattutto, di facilità d'uso.
Quest'ultima caratteristica si può ritenere strategica e cruciale ai fini della diffusione su
larga scala delle tecnologie domotiche in ambito residenziale. Si parte, infatti, da un
pubblico potenziale abituato ad utilizzare quotidianamente dispositivi di comando
estremamente semplici ed intuitivi:
dall'interruttore, ai cursori o commutatori di posizione, fino al componente più
complesso rappresentato dal telecomando a raggi infrarossi. Non si deve, quindi,
sottovalutare l'impatto che può rappresentare l'impiego di visualizzatori e console di
comando più complesse, del resto necessarie per sfruttare appieno i vantaggi
dell'integrazione domotica. Le soluzioni più significative sembrano, in ordine di
complessità crescente, quelle costituite da telecomandi ad infrarossi dedicati alle singole
applicazioni
(illuminazione,
riscaldamento,
serramenti)
ovvero
telecomandi
multifunzione, dove è però richiesto un display, cioè la possibilità di interagire in
maniera semplice con un video, possibilmente lo stesso televisore domestico. Su un
livello di maggiore complessità, si situano invece le interfacce basate su pc che
richiedono una maggiore consapevolezza e determinazione nell'uso da parte
dell'utilizzatore. Quest'ultima soluzione, destinata comunque ad un pubblico
selezionato, può essere resa di più facile impiego col ricorso a dispositivi portatili (quali
sono ad esempio i moderni palmari di uso generale o dedicati eventualmente all'uso
domestico ed eventualmente distribuiti nei diversi ambienti), o a dispositivi dedicati con
speciali potenzialità grafiche e periferiche, quali touch-screen, in grado di presentare in
maniera evidente una mappa della casa. Infine, le diverse possibilità di telecomando a
distanza suggeriscono l'impiego della linea telefonica e quindi dei terminali telefonici
fissi, cordless o portatili come strumento di interfaccia, con ausilio di display (testo o
grafico) o con l'ausilio di guida e comandi vocali. In tutti i casi comunque devono essere
verificate le modalità operative delle soluzioni proposte poiché, anche le soluzioni più
interessanti, possono ottenere una scarsa accettazione per particolari apparentemente
insignificanti o non particolarmente graditi.
Come si è visto, le reti di comunicazione all'interno di un complesso che si avvale
dell'automazione domestica possono essere diverse, e per ciascuna di esse si presenta la
necessità di comunicare con una rete esterna, sia per implementare opzioni di
143
telecomando dei dispositivi e di sorveglianza, sia per accedere a flussi di informazioni
(voce via telefono, dati per Internet, trasmissioni analogiche o digitali, per
intrattenimento). È auspicabile che il punto di comunicazione con l'esterno sia unico ed
opportunamente protetto e sicuro. Il punto di comunicazione della rete domotica verso
l'esterno è costituito da un dispositivo in grado di far convergere i diversi flussi di dati,
instradandoli nel rispetto dei vari protocolli verso l'esterno. A questo componente, che
ha necessariamente una configurazione variabile con le esigenze specifiche, si da il
nome di Residential Gateway, o interfaccia residenziale. Grazie ad esso la rete
domestica, che si può classificare quando isolata come una rete locale (LAN, Local
Area Network), diventa un elemento di una più vasta rete in area estesa (WAN, Wide
Area Network). Le interfacce attualmente presenti sul mercato sono proposte
generalmente da costruttori e installatori di linee telefoniche e linee dati, che sono i
primi interessati commercialmente a diffondere le rispettive tecnologie in forma
integrata. Esse nascono da esigenze dell'automazione d'ufficio e, in secondo luogo, si
rivolgono al mondo dell'automazione dell'edificio. Ma è proprio grazie alla possibilità di
un'estesa diffusione dell'automazione domestica, comprendente le comunicazioni a
larga banda per voce e intrattenimento, che possono svolgere un ruolo chiave nel
superamento della molteplicità dei protocolli. Tra i dispositivi di questa categoria
rientrano per esempio i comunicatori GSM, le interfacce tra BUS e Internet, Interfacce
telefoniche, etc.
6.2 Il Mercato
Dopo aver fornito i principi fondamentali e i componenti alla base di un sistema
domotico attuale, proseguiamo fornendo alcune informazioni riguardanti i produttori di
tecnologie relative a questo campo presenti oggi sul mercato.
Analizzando la documentazione prodotta delle aziende del settore, cresce continuamente
il numero di dispositivi, sia da un punto di vista quantitativo, ma soprattutto qualitativo.
L'offerta si sta specializzando, mettendo così a disposizione una vasta gamma di
prodotti che possono soddisfare le sempre più complicate ed eterogenee esigenze del
cliente finale. Abbiamo visto che esistono protocolli standard (riconosciuti o de facto),
144
protocolli proprietari, protocolli standard nel mondo del ICT, protocolli standard
industriali. Lo scenario è abbastanza diversificato sotto questo aspetto, e nonostante il
continuo crescere del processo di standardizzazione, sono presenti sul mercato molti
protocolli di comunicazione diversi e conseguentemente tecnologie differenti.
Nel mondo della domotica possiamo comunque fare una distinzione tra soluzioni
consortili e soluzioni non consortili.
I Consorzi nel settore della domotica sono caratterizzati da:
- essere conforme alle Norme
- avere le specifiche disponibili pubblicamente
- poter accettare apparecchiature multi-costruttore
- garantire l'interoperabilità tra le apparecchiature
- deve assicurare l'espandibilità dell'impianto con apparecchi di diversi costruttori.
Oltre alle soluzioni di tipo Consortile, si sono prese in considerazione anche altre
soluzioni che trovano spazio nel mercato italiano e che rispondono alla domanda di
prodotti e soluzioni sia nel settore dell'home automation che della building automation.
Spesso queste soluzioni adottano protocolli di comunicazione detti Proprietari oppure
sono modifiche di protocolli standardizzati.
6.2.1 Il sistema KONNEX
KNX è un sistema di controllo degli edifici decentralizzato, pilotato da eventi con
trasmissione dati seriale per le funzioni operative di controllo, monitoraggio e
segnalazione. Tramite una linea di trasmissione comune, tutti gli apparecchi collegati
possono scambiarsi informazioni. La trasmissione dati avviene in modo seriale secondo
regole stabilite: il protocollo di trasmissione.
Le informazioni da trasmettere sono organizzate nel cosiddetto telegramma ed inviate
da un apparecchio (il mittente) ad uno o più apparecchi (il/i destinatario/i). Ogni
destinatario conferma la ricezione del telegramma; se ciò non avviene, l'invio del
telegramma viene ripetuto. Se la ricezione del telegramma non viene confermata, la
procedura di invio viene interrotta e l'errore viene registrato nella memoria del
trasmettitore. I telegrammi vengono modulati su tensione continua; uno zero logico
viene trasmesso come impulso mentre l'assenza di impulsi viene interpretata come un 1
logico. I singoli dati dei telegrammi vengono trasmessi in modo asincrono. La
145
trasmissione viene comunque sincronizzata grazie ai bit di avvio e stop. L’accesso al
bus come mezzo di comunicazione fisico comune per trasmissione asincrona deve
essere comunque regolato in modo chiaro. Il sistema KNX impiega a questo scopo il
protocollo CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance); si tratta di
un metodo di accesso casuale al bus esente da collisioni senza peraltro diminuire la
portata dei dati sul bus. Tutti gli apparecchi sono permanentemente in ascolto del bus;
se un apparecchio bus vuole inviare un telegramma deve dapprima controllare che
nessun altro apparecchio stia già trasmettendo (Carrier Sense). Se il bus è libero ogni
apparecchio collegato può iniziare la procedura di invio (Multiple Access). Se due
apparecchi iniziano a trasmettere contemporaneamente, prevale l’apparecchio che ha
priorità più alta (Collision Avoidance), mentre l'altro apparecchio interrompe la
procedura per riavviarla successivamente. Se entrambi gli apparecchi hanno la stessa
priorità, prevale quello con indirizzo fisico inferiore.
Esistono fondamentalmente tre tipi diversi di configurazioni realizzabili al momento
dell’istallazione:
S-Mode
(System
Mode)
adatta
ad
integratori
di
sistema
ed
orientata
all’implementazione di funzioni complesse. Tutti i componenti "System Mode",
connessi alla rete, possono essere indirizzati tramite un unico tool software (ETS),
comune a tutti i costruttori, che consente di programmare, configurare e stabilire le
connessioni. Mediante ETS è possibile programmare ciascun componente in base alla
funzione cui è destinato in un progetto. Consente un elevato livello di flessibilità sia dal
punto di vista funzionale sia riguardo ai collegamenti.
A-mode (Automatic mode): pensata per permettere all’utente finale la connessione
automatica di nuove applicazioni, riguarda prodotti destinati al mercato consumer. I
componenti
"Automatic mode" si avvalgono di una modalità di configurazione automatica che
adatta i loro link di comunicazione a quelli di altri componenti "Automatic mode" che si
trovano nella rete. Ciascun componente contiene un numero fisso di parametri da
impostare ed una libreria con le istruzioni su come far colloquiare i componenti.
E-mode Configurazione semplice (Easy), realizzata senza l'uso di un PC, in genere si
utilizzano dispositivi specifici chiamati configuratori oppure semplici dip-switches
presenti nei dispositivi; i dispositivi E-Mode realizzano funzioni limitate, ma comunque
adatte per applicazioni di Home Automation; per la loro configurazione è sufficiente
146
una formazione minima di base facilmente acquisibile da qualsiasi installatore. Quindi
E-Mode è una tipologia di installazione per impianti di piccole e medie dimensioni,
dove non si richiedono soluzioni complicate; le pecularietà dell’S-mode, invece, sono:
l’essere liberamente programmabile; possedere un unico tool di progettazione ed avere
alte prestazioni e funzioni; è adatto a professionisti con una buona formazione.
Figura 1.6 Sistema KONNEX, schema di principio
6.2.2 Sistema LONMARK
Sviluppata da Echelon, la tecnologia Lonmark è stata fatta propria dall'EIA (Electronic
Industries Alliances) ed integrata nello standard americano EIA-709. Lo standard
LonWorks è uno standard aperto ovvero accessibile a tutti ed il cui uso non prevede il
pagamento di alcuna royalty. I dispositivi Lonworks comunicano attraverso il protocollo
LonTalk, basato sull'implementazione di tutti i livelli dello schema ISO/OSI. I nodi
della rete Lon hanno come componente principale il Neuron chip (ci ricorda il
microcontrollore utilizzato nel nostro sistema ausilio), un circuito integrato che integra
tre processori di cui due dedicati alla gestione del protocollo Lontalk. Ogni nodo è
costituito da un Neuron Chip, un transceiver ed un circuito elettronico specifico per
l'applicazione. Echelon ed i produttori dell'integrato controllano il firmware dei primi
due processori, mentre il progettista può programmare il terzo attraverso, per poter
svolgere le funzioni a cui il nodo è dedicato. Il protocollo LonTalk prevede l'uso di
variabili SNVT ( Standard Network
147
Variables Types), cioè tipologie di variabili atte a rappresentare una grandezza.
L'utilizzo e la gestione di queste variabili permette e facilita l'interoperabilità dei diversi
dispositivi che devono utilizzare le stesso formato di variabili, con conseguente
diminuzione della complessità dei messaggi.
I principali elementi della tecnologia LonWorks sono rappresentanti dunque da:
•
il NeuronChip che è il cuore di ogni nodo LonWorks può gestire i dispositivi
I/O ed eseguire un codice scritto dall'utilizzatore.
•
il protocollo LonTalk è un protocollo di comunicazione aperto basato sul
modello di riferimento OSI. Definisce un modo standard per lo scambio di
informazioni tra i nodi. Nel 1999 l'ANSI l'ha ratificato come standard ufficiale:
ANSI/EIA 709.1 ± A ± 1999.
•
il transceiver: un dispositivo che realizza la connessione elettrica del Neuron
Chip ai mezzi di comunicazione.
•
le interfacce di rete che sono usate per connettere un Computer alla rete
LonWorks.
•
gli applicativi (Tools) sono necessari per sviluppare, mettere in opera e
mantenere le reti. A tale categoria appartengono il LonBuilder Developer's
Workbench, il NodeBuilder Tool, il Lon Maker per Windows etc.
Figura 1.7 Sistema LONMARK, schema a blocchi
148
I sistemi Lonmark e KNX descritti brevemente nelle righe precedenti, rappresentano
proprio dei sistemi, questo prevede che i componenti utilizzati possono provenire da
diversi fornitori, a patto che vengano rispettate le specifiche dei protocolli.
Per quanto riguarda le case produttrici di veri e propri dispositivi organizzabili in
sistemi domotici, la principale sul mercato Italiano è senza dubbio la BTicino.
6.2.3 BTicino[21]
Offre sostanzialmente il sistema componibile MYHOME realizzato tramite l'utilizzo
della stessa tecnologia impiantistica, basata sul bus digitale, che consente di creare una
sinergia tra i vari componenti del sistema in funzione delle scelte e delle esigenze del
cliente. Il sistema MYHOME rende disponibile le seguenti funzionalità:
- Automazione luci e scenari
- Automazione tapparelle
- Diffusione Sonora
- Antifurto
- Termoregolazione
- Gestione energia
- Citofonia e videocitofonia digitale
- Telefonia Integrata
- Cablaggio Multimediale
- Dispositivi di controllo
Figura 1.8 Sistema Myhome
149
Il supporto fisico è costituito da un cavo ad una coppia ritorta e non schermata, al quale
sono connessi in parallelo tutti i dispositivi del sistema. In casi particolari è possibile
estendere un impianto filare con opportune interfacce radio. In questo caso i dispositivi
impiegano la stessa tecnologia utilizzando come supporto di comunicazione le onde
radio anziché la connessione al bus.
In realtà negli ultimi anni la proposta tecnologica sta subendo una crescita costante,
garantendo un’ampia scelta all’utenza interessata. La domotica però, rimane ancora
relegata ad un settore di mercato dedicato a soluzioni abitative di livello medio-alto,
destinate a utenti generici.
Le soluzioni sono molto spesso ancora molto costose (il sistema MyHome completo di
tutte le sue parti e funzionalità raggiunge il costo di 20000 euro!), non permettendone
un’adeguata
distribuzione
all’interno
della
maggioranza
delle
utenze.
La
progettazione/realizzazione del sistema ausilio presente e descritta a fondo nei capitoli
precedenti in questo lavoro, si propone di prototipizzare una possibile soluzione che,
sicuramente dopo un adeguato lavoro di sviluppo e perfezionamento, possa fornire una
risorsa dedicata al riempimento di questa lacuna all’interno del mercato, arricchendolo
di soluzioni customizzate per gli utenti diversamente abili. Nella prima parte del
capitolo infatti, è stata riportata una descrizione dei principi, oramai abbastanza
consolidati, che vengono seguiti dai diversi sistemi domotici presenti sul mercato. Da
quanto detto, si percepisce come non ci sia ancora una formalizzazione concettuale
dedicata all’utenza disabile, che permetterebbe di individuare le necessità di queste
persone nei confronti di un impianto di tipo domotico. Parlando di interfaccia, le
caratteristiche predominanti rimangono ancora quelle legate alla semplicità d’uso, senza
considerare come fondamentale l’accessibilità, indispensabile nei casi considerati. Per
questi motivi, il sistema realizzato, concepito proprio per utenti diversamente abili,
segue le linee guida dell’accessibilità, della bidirezionalità comunicativa customizzata
alle esigenze, dei costi contenuti e della semplicità istallativi, garantendo la
preservazione massima degli attuatori presenti già nell’abitazione.
Per concludere quindi, diciamo che un impianto domotico potrebbe essere concepito e
realizzato, col fine di prediligere il miglioramento delle qualità di vita è legata ai
seguenti aspetti:
150
•
l'invecchiamento della popolazione rappresenta certamente il fenomeno
demografico più rilevante degli ultimi anni a causa delle sue molteplici
conseguenze di natura economica e sociale. Allo stesso tempo tale
invecchiamento
solleva
problemi
notevoli
sul
piano
dell'assistenza
sociosanitaria. I servizi di telesoccorso e di teleassistenza costituiscono in tale
senso, un notevole mercato potenziale perché rappresentano un interessante
segmento del mercato dell'Home Automation;
•
miglioramento
nell'autonomia
delle
persone
disabili
attraverso
l'automatizzazione, il controllo e la gestione dell'edificio tramite interfacce
studiate per particolari inabilità quali, ad esempio, telecomandi a controllo
vocale o interfacce telefoniche.
•
alleviamento delle condizioni di debilitazione di un malato, anziano, disabile,
realizzato con strumenti che da un lato permettano di ridurre la fatica fisica e
aumentare la mobilità, dall'altro facilitano l'accesso ai mezzi di comunicazione
(ad esempio strumenti per la comunicazione a distanza audio e video con altre
persone) o più semplicemente svolgano un'azione di intrattenimento
151
7. UNA POSSIBILE APPLICAZIONE
7.1 Caratterizzazioni
Arrivati a questo punto, possediamo tutti gli elementi necessari a caratterizzare e
realizzare un sistema ausilio domotico completo.
Dalle considerazioni fatte nel capitolo precedente, possiamo affermare che il sistema
che ci si propone di realizzare avrà le seguenti caratteristiche:
1. sarà un sistema a intelligenza distribuita;
2. avrà un’architettura a stella;
3. utilizzerà la trasmissione in radiofrequenza come mezzo trasmissivo;
4. sarà caratterizzato da un protocollo comunicativo di tipo seriale;
Per chiarezza, riassumiamo brevemente quanto sviluppato fino a questo momento:
abbiamo realizzato l’hardware che andrà a caratterizzare un circuito di controllo dotato
dell’intelligenza sufficiente a comandare l’attuatore e a verificarne lo stato. Dal lato
utente, disponiamo di un’host, rappresentato da un personal computer, potenziato nella
sua accessibilità. Proprio questi due elementi costituiscono le parti principali del sistema
ausilio.
152
Il PC costituisce il centro della struttura a stella descritta precedentemente, strutturata
come da schema :
Figura 2.1. Configurazione a stella.
Il nodo centrale è rappresentato ovviamente dall’host che gestisce le unità periferiche
collegate agli attuatori. Questa configurazione, come detto, permette una maggior
robustezza, possibili danni alle unità periferiche non influenzano infatti la rete nel suo
insieme, il controllo è semplificato dipendendo solo dall’unità centrale, garantendo
inoltre alte prestazioni.
Dalla natura stessa delle unità periferiche deriva il carattere distribuito delle capacità
computazionali. Ogni circuito di controllo, realizzato su base microcontrollore
Microchip, possiede una propria intelligenza che ne permette la comunicazione sia con
il centro di controllo (l’host) che con l’applicativo collegato a valle. Ogni unità
periferica, concepita per ricevere ed inviare segnali conformi al protocollo EIA RS-232
(a riguardo consultare la prima sezione), è fornita del noto convertitore EZL-80 che gli
permette di implementare una trasmissione wireless che soddisfi le specifiche del
protocollo Wi-Fi. Questo permette un decentramento ottimale delle unità periferiche che
possono essere distribuite, senza la posa e il cablaggio di fili aggiuntivi, all’interno
dell’abitazione, in corrispondenza dei dispositivi domotici e dei gruppi per
l’illuminazione. L’utente invece potrà sempre controllare lo stato dei dispositivi dalla
Power Station che, se realizzata tramite i recentissimi ultra mobile pc (Samsung Q1
153
Ultra, Asus EEE PC) sarà portatile e facilmente installabile su un eventuale carrozzina
utilizzata dall’utente stesso.
I componenti principali sono quindi tutti definiti, quello che manca nella trattazione è
legato al lato attuatore e al feedback che deve essere captato in qualche modo dal
circuito di controllo.
Di seguito procederemo proprio all’elaborazione di una delle possibili applicazioni. In
particolare, lo scenario immaginato prevede la presenza di utenza con disabilità visiva o
motoria tale che, il soggetto in esame, non sia né in grado di accendere le luci in modo
autonomo, né di ricevere un ritorno sensoriale appropriato per determinare se le stesse
luci sono accese o meno.
I costituenti necessari per realizzare questo tipo di applicativo sono fondamentalmente
due:
•
Un gruppo luminoso di vario genere, alimentato comunemente con
alimentazione di rete.
•
Un circuito progettato e realizzato ad hoc per produrre un segnale adeguato in
corrispondenza dell’accensione delle luci.
Di seguito quindi descriveremo in dettaglio questi due componenti, per poi descrivere il
funzionamento del sistema ausilio nel suo complesso.
7.2 L’applicativo
Come applicazione si è quindi scelto di controllare lo stato dell’illuminazione, in
particolare, l’accensione e lo spegnimento di una generica lampada a piantana. La
lampada è stata scelta tra le più comuni, proprio per testare il grado di adattabilità del
circuito di controllo. Come già detto, è a livello dell’alimentazione che avviene la
regolazione da parte del circuito, in questo modo, sarà facile poter implementare un
controllo su un generico applicativo dotato di un’alimentazione esterna. Lo sviluppo di
questa parte ha seguito in realtà una certa evoluzione. Nelle prime fasi, per semplicità è
stato realizzato un circuito su basetta millefiori che comprendeva lo stadio di controllo a
transistore bipolare, il relais e una semplice lampadina da 10W (foto), che potesse
154
essere alimentata efficacemente da 1A a 12V forniti da un comune alimentatore. In
questo modo, le prime prove, prevedevano l’utilizzo della medesima alimentazione
utilizzata per il circuito di controllo. L’immagine seguente illustra proprio questa
soluzione prototipale, molto efficacie e funzionale per verificare semplicemente il
funzionamento dello schema di principio utilizzato.
Figura 2.2. Prime fasi di sviluppo: l'attuatore. Il circuito comprende lo stadio di controllo transistor, il
relais e una lampada da 10W alimentata a 12V.
Lo step successivo è stato quello di adattare i risultati ottenuti in fase di test, ad una
soluzione che potesse avvicinarsi maggiormente ad un’idea definitiva di applicazione. A
questo scopo è stata utilizzata una normale lampada da tavolo alimentata tramite la rete.
Nelle figure seguenti, sono evidenziate le modifiche minime da improntare per rendere
possibile il controllo. Ciò che è necessario è interporre il relais, controllato tramite
stadio transistor (spostato in questa fase sul circuito di controllo) dal microcontrollore,
tra la lampada e la rete, così da realizzare semplicemente il controllo desiderato del lato
attuatore. Per fare ciò si connette il conduttore di fase al relais, come illustrato nello
schema seguente, mentre il conduttore di terra viene mantenuto integro. In particolare, il
circuito relais comprende gli ingressi necessari per realizzarne il collegamento allo
stadio transistor (ingressi 2 e 3) e un’uscita tramite la quale vengono trasportati i 12V
necessari all’alimentazione del circuito di feedback descritto tra poco. Questo tipo di
155
collegamento potrebbe sembrare estremamente artificioso, in realtà permette di
minimizzare il numero di alimentatori utilizzati. Una soluzione più immediata, ma
sicuramente più complessa e costosa, prevedrebbe di ottenere le alimentazioni
necessarie, lato attuatore, a partire dalla rete. Questo presuppone la realizzazione di un
trasformatore dedicato per ricavare dai 220V in alternata i 12V in continua. Tale
approccio è stato tralasciato, la costruzione di un trasformatore non è infatti di interesse
per lo sviluppo del progetto in esame. Per questo motivo si è preferito attingere, dove
necessario, all’unica alimentazione a 12V utilizzata, ovvero quella presente sul circuito
di controllo.
Figura 2.3. Circuito Realais lato saldature installato sulla lampada controllata. In evidenza
l'interposizione del relais all'alimentazione della lampada e gli ingressi/uscite che collegano l’attuatore
agli altri componenti.
156
Figura 2.4. Un attuatore generico. Il circuito relais si interpone semplicemente tra la lampada e
l'alimentazione. Il controllo da parte del circuito di controllo avviene a questo livello.
Passando dalla fase di test a quella applicativa vera e propria, lo stadio di controllo a
BJT viene spostato sul circuito di controllo, mentre il circuito relais rimarrà lato
attuatore come da figura.
Lo schema seguente, ottenuto col solito cad, evidenzia proprio la divisione di questi due
stadi circuitali.
Figura 2.5 diagramma del circuito relais. Il riquadro nero racchiude i componenti del circuito relais che
viene connesso alla lampada, all'alimentazione di rete e riceve in ingresso, dal circuito di controllo, i 5V e
i 12V. Nel riquadro rosso, lo stadio di controllo a transistor, che nelle fasi di sviluppo viene integrato nel
circuito di controllo.
157
La spiegazione di questa separazione risiede nell’analisi delle diverse alimentazioni
utilizzate. Mentre infatti lo stadio transistor necessita dei 12V e 5V, disponibili per altro
sul circuito di controllo (consultare la sezione corrispondente nel capitolo riguardante il
Circuito di controllo), il relais dovrà essere collegato alla tensione di rete, dovendo
realizzare l’interruttore controllato in tensione che determina l’accensione o lo
spegnimento della lampada utilizzata. In questo modo otterremo una separazione della
circuiteria alimentata a tensione di rete, da quella di controllo, alimentata a basse
tensioni. È utile sottolineare che, per avere un adeguato isolamento galvanico,
proponiamo di aggiungere un optoisolatore (tipo ISO100) capace di realizzare una
separazione efficace dei due stadi, a scopo di sicurezza da guasti provenienti dal
contatto tra le tensioni di rete e le parti low voltage (essenzialmente il circuito di
controllo in logica TTL).
Ci siamo già occupati dello stadio a transistor e dello schema corrispondente; per quanto
riguarda il relais, è stato montato su una basetta millefori improntata in modo da
disporre di ingressi e di uscite. I connettori presenti sulla basetta permettono i seguenti
collegamenti:
•
Il numero 1 e il numero 2 servono a fornire 12V e 5V al relais e consentono di
realizzare il circuito per il controllo in tensione della bobina;
•
Il numero 3 fornisce 12V per l’alimentazione del circuito di feedback.
Questo tipo di collegamento potrebbe sembrare estremamente artificioso, in realtà
permette di minimizzare il numero di alimentatori utilizzati. Una soluzione più
immediata, ma sicuramente più complessa e costosa, prevedrebbe di ottenere le
alimentazioni necessarie, lato attuatore, a partire dalla rete. Questo presuppone la
realizzazione di un trasformatore dedicato per ricavare dai 220V in alternata i 12V in
continua. Tale approccio è stato trascurato, non essendo di interesse, per lo sviluppo del
progetto in esame, la costruzione di un trasformatore. Pertanto si è preferito attingere,
dove necessario, all’unica alimentazione a 12V utilizzata, ovvero quella presente sul
circuito di controllo.
Di seguito sono riportate alcune immagini riguardo le fasi di test del collegamento tra
l’applicativo ed il circuito di controllo.
158
7.3 Il circuito di Feedback
I componenti progettati e assemblati fino a questo momento realizzano un sistema di
controllo per un generico impianto di illuminazione domestico. Ricordiamo che tale
controllo dovrà essere messo a disposizione di un utente afflitto da grave disabilità
visiva o, in aggiunta, da limitazioni dettate da handicap fisici tali da non garantire al
soggetto la capacità di verificare se le stesse luci sono accese o spente. In tali
condizioni, il sistema ausilio deve essere capace sia di controllare l’illuminazione, sia di
fornire consono ritorno all’utente finale. A questo livello entra in gioco il circuito di
feedback, concepito proprio per “comunicare” al PIC16F628 se l’evento desiderato
(accensione della luce) si verifica a seguito della richiesta dell’utente oppure no.
L’elemento fondamentale, che garantisce la realizzazione di un adeguato feedback per
un’applicazione del genere, deve necessariamente essere in grado di rispondere a
significative variazioni della luminosità ambientale. A questo scopo è stato realizzato
hardware basato sul TSL250 della Texas Instruments[22].
Figura 2.6 TSL250. Schematizzazione dal datasheet.
159
Figura 2.7 Pin e dimensioni reali del TSL250
L’integrato possiede tre piedini, il numero 1 viene collegato a massa, il numero 2
all’alimentazione e il numero 3 fornisce la tensione di uscita proporzionale all’intensità
di radiazione luminosa incidente sul fotodiodo. La tensione di alimentazione VDD deve
essere compresa tra i 3V e i 10V, con valori tipici di 5V.
Questo componente è fondamentalmente un sensore ottico light-to-voltage; al suo
interno contiene un fotodiodo e un amplificatore a transimpedenza con resistore di
feedback da 16MΩ. La tensione fornita in output è direttamente proporzionale
all’intensità luminosa (irradianza) presente sul fotodiodo. Per chiarire questo concetto,
riportiamo di seguito diagramma funzionale a blocchi estratto dal datasheet
dell’integrato.
Figura 2.8.Schema a blocchi del TSL250
160
L’incidenza di radiazione luminosa provoca la polarizzazione inversa del fotodiodo con
conseguente passaggio di corrente I, come illustrato in figura. A questo punto,
risolvendo la maglia avremo:
•
VI − ZI − VO = 0;
Da questa relazione otteniamo semplicemente (VI = 0) che VO = ZI. Quindi la tensione
di uscita è proporzionale alla corrente che scorre nel fotodiodo che è data dalla somma
di due contributi:
•
La corrente del diodo espressa dalla relazione di Shokley;
•
iph = σP, corrente fotogenerata nella regione di svuotamento (è una corrente
inversa e dipende dalla potenza ottica dell’illuminazione incidente);
La relazione che permette di calcolare la corrente è quindi la seguente:
⎛ ηVV
⎞
T
⎜
I = i0 e − 1⎟ − i ph
⎜
⎟
⎝
⎠
Dove:
•
VT è il valore equivalente in Volt della temperatura, che in caso di temperatura
ambiente vale 25mV
•
I0 è la corrente inversa di saturazione (detta corrente di buio)
•
η è il fattore di idealità della giunzione e dipende dal materiale semiconduttore
(η = 1 per Ge; η = 2 per Si)
Da questa relazione è quindi evidente che la corrente (e quindi la tensione di uscita)
dipenderà dalla radiazione incidente. Semplificando, questo componente si comporta
come un resistore variabile: all’aumentare della luminosità incidente sul fotodiodo, la
resistenza diminuisce e quindi diminuisce la caduta di tensione tra alimentazione e
uscita. Al limite, quando ho irradianza massima, il TSL250 fornisce in uscita una
tensione che tenderà al valore di VDD.
I grafici seguenti, estratti dal datasheet del componente, descrivono alcune delle
caratteristiche salienti dell’integrato considerato, ritenuto consono alla soluzione
circuitale proposta.
161
Figura 2.9. In alto: relazione tra l’irradianza e la tensione d’uscita. In basso: relazione tra tensione di
alimentazione e tensione d’uscita.
Il primo evidenzia il legame di tipo logaritmico esistente tra la tensione di uscita e
l’irradianza incidente sul fotodioido. Il secondo sottolinea come, la relazione esistente
tra la tensione di alimentazione e quella di uscita, per un valore fissato di irradianza, sia
di tipo lineare.
162
Questo particolare fotorilevatore garantisce inoltre una Responsività massima (rapporto
tra la corrente prodotta e la potenza ottica incidente) in corrispondenza di radiazione
avente lunghezza d’onda appartenente allo spettro del visibile.
Figura 2.10. Responsività in funzione della lunghezza d’onda.
Proprio questa caratteristica permette performance elevate in un’applicazione come
quella descritta.
Figura 2.11. Tensione d’uscita normalizzata in funzione dell’angolo di incidenza.
163
Il voltaggio prodotto in uscita dipende inoltre dall’angolo di incidenza della luce
calcolato rispetto all’asse ottico del fotodiodo. In particolare la massimizzazione del
valore della tensione è ottenuto in corrispondenza di un angolo di 0° rispetto all’asse.
Questo risultato fornisce indicazioni sulla disposizione del circuito di feedback rispetto
alla fonte luminosa proveniente dall’attuatore.
A questo punto vediamo qual è il contesto circuitale nel quale viene inserito il TSL250,
così da realizzare lo stadio di feedback.
164
Figura 2.12. Schema Orcad dello stadio di feedback a fotodiodo
165
12V
R11
7k
R10
10k
T SL250
GND
VDD
Vout
1
2
3
3
2
-
+
U6
R6
200k
LM311
R5
14k
G
OUT
B/S
8
5
V+
B
V4
1
7
6
R8
680
R7
1.5k
FEEDBACK al PIC
D1
R9
680
Figura 2.13. Il circuito di feedback a fotodiodo, vista lato componenti.
Prima di descrivere i singoli componenti, anticipiamo brevemente che la tensione
prodotta dal fotorilevatore, legata alla radiazione luminosa incidente, viene comparata
ad un livello di riferimento, appositamente dimensionato. Se supera questo riferimento,
il circuito produce una tensione in uscita (utilizzabile dal microcontrollore), se invece la
tensione non supera il valore di soglia (illuminazione insufficiente), non viene prodotta
alcuna tensione in uscita, ma si verifica l’accensione di un diodo led di segnalazione.
Vediamo dall’analisi particolare dei componenti come sia possibile tutto ciò. Si è già
parlato del TSL250 che realizza la conversione irradianza-tensione e che viene usato da
fotorilevatore. L’altro integrato fondamentale per il funzionamento dell’hardware è il
comparatore LM311[23]. Questo IC è, come detto, un comparatore integrato molto
versatile che fornisce ottime prestazioni per quanto riguarda sia il tempo, sia la
precisione della risposta. Esso può essere alimentato con alimentazione duale ±15V,
oppure con alimentazione unipolare da 5V a 30V, ciò consente una notevole
semplificazione dei circuiti di alimentazione.
166
Figura 2.14. Schematizzazioni tratte dal datasheet del LM311.
Un altro aspetto molto interessante è costituito dal fatto che il 311 può pilotare
direttamente circuiti digitali TTL, CMOS, MOS indipendentemente dai valori
dell'alimentazione Questo componente è interpretabile come un operazionale seguito da
un BJT con collettore ed emettitore aperti. Quando l'ingresso IN+ è più positivo
dell'ingresso IN-, il transistore di uscita è in interdizione (OFF). Quando l'ingresso IN+ è
più negativo dell'ingresso IN-, il transistore di uscita è in saturazione (ON).
Il terminale del collettore deve essere collegato, tramite un'opportuna resistenza, ad una
sorgente di alimentazione positiva (con un valore massimo di 40V rispetto al terminale VCC). Il terminale di emettitore viene connesso normalmente a massa.
La struttura a collettore aperto consente anche di collegare più comparatori in
configurazione Wired-OR, quando si vuole implementare più operazioni di confronto.
Altra particolarità del 311 è la presenza dell'ingresso di strobe (terminale 6, indicato con
B/S, per bilanciamento e strobe). Il piedino di strobe consente di abilitare o disabilitare
il funzionamento del comparatore. Quando lo strobe è a livello alto, fluttuante o
collegato a VCC, il comparatore funziona normalmente. Quando lo strobe è basso,
collegato a massa attraverso una resistenza che limiti la corrente a 3 – 5 mA (in genere
di 10 KΩ ), l'uscita rimane a livello alto, indipendentemente dai segnali presenti sugli
ingressi. Tale caratteristica consente di effettuare comparazioni di segnali in
sincronismo con determinati stati di un sistema o con temporizzazioni particolari. Il
piedino 6, collegato al piedino 5 con un trimmer il cui cursore è collegato a +VCC,
consente di regolare l'offset del comparatore.
167
Di seguito riportiamo, contenuta nel riquadro in rosso, la parte del circuito che realizza
la comparazione dei livelli di tensione.
Figura 2.159. Nel riquadro in rosso il comparatore LM311 e i relativi collegamenti.
In pratica, la tensione di riferimento è quella misurata nel punto Vo ed è assegnata
tramite un partitore di tensione resistivo, infatti dall’analisi dello schema è immediato
rilevare che:
•
Vo =
R6
12V
R6 + R5
Il segnale in ingresso VIN, proviene direttamente dal TSL250 e sarà pertanto legato al
livello di luminosità che incide sull’IC. Se la tensione di ingresso sul terminale V+
supera la soglia, dimensionata opportunamente, l’operazionale produce in uscita una
tensione prossima alla +Vsat (che coincide con +VCC=5V nel nostro caso). Questo
provocherà passaggio di corrente dal terminale alimentato a 12V verso l’uscita destinata
al microcontrollore che riceverà quindi un segnale in ingresso quando la luminosità
provoca il superamento della tensione soglia Vo. Al contrario, se la luminosità non è
sufficiente a produrre una tensione tale che venga superato il valore di riferimento,
l’OPAMP produce in uscita una tensione prossima al valore −Vsat (che tende al valore di
alimentazione −VCC=0V ), determinando passaggio di corrente nel ramo del diodo led e
168
provocandone di conseguenza l’accensione. Questo evento viene preso come segnale di
luminosità inferiore alla soglia di tensione fissata in modo opportuno.
Proprio la “taratura” della tensione di riferimento è cruciale per ottenere un
comportamento opportuno del feedback. Lo scopo dello stadio circuitale analizzato è,
infatti, quello di produrre un segnale significativo solo nel momento in cui il gruppo
luminoso, controllato dall’utente a mezzo del sistema ausilio, viene effettivamente
acceso, non considerando l’eventuale aumento della luminosità ambientale come
significativa (onde evitare messaggi di “luce accesa” in caso di incremento della sola
luminosità ambientale).
Figura 2.16. Un particolare del circuito di feedback.
Per discriminare tra queste possibili configurazioni sono state effettuate misurazioni sul
TSL250 per verificarne il range di tensione presentata in uscita, al variare delle
condizioni di luminosità. Gli scenari considerati sono tre:
•
presenza di luce ambientale: dove con ambientale si intende la luce artificiale
prodotta da un gruppo luminoso non puntato direttamente sul fotodiodo, in
aggiunta alla luminosità proveniente dall’ambiente esterno (luce solare);
•
assenza di luce sia ambientale che artificiale;
•
luce diretta puntata sul fotodiodo: questa configurazione simula proprio la
situazione nella quale il circuito deve produrre il feedback desiderato.
169
Le misure sono state compiute con un normale tester, tramite il quale è stato possibile
misurare la tensione presente sul pin numero 3 dell’IC Texas; l’integrato è stato
alimentato tramite un normale alimentatore stabilizzato a 5V (VDD), i risultati sono
riportati nella seguente tabella.
Luce Ambientale
Luce Assente
Luce Diretta
VDD
5V
5V
5V
VO
2,8V
0,14V
4.6V
Figura 2.17. Tensione d’uscita al variare del livello luminoso
Dai dati ottenuti è facile discernere che, allo scopo di garantire un funzionamento in
situazioni che si avvicinino il più possibile a quella di un uso comune, la soglia di
tensione che il comparatore utilizza da riferimento dovrà avere un valore compreso tra i
2,8V (presenza di luce ambientale) e i 4,6V (illuminazione diretta). Per ottenere il
valore di tensione voluto, basta agire scegliere in modo opportuno le resistenze di
partitore, R5 e R6. In particolare, fissato R5, calcoleremo R6 (un trimmer in realtà),
variando il quale si potrà adattare il comportamento del circuito in base a cambiamenti
delle condizioni di luminosità ambientale. Per quanto riguarda la scelta del riferimento,
il valore di 4V è stato considerato opportuno onde evitare che scenari di luce ambiente
particolarmente forte vengano confusi con un’illuminazione diretta proveniente
dall’attuatore vero e proprio. Fissati:
•
Vo = 4V;
•
R5 = 14kΩ;
Dato che:
•
Vo =
R6
12V ;
R6 + R5
Otteniamo per R6 il valore molto prossimo ai 6kΩ. Durante la fase di realizzazione è
stato utile poter modificare il valore di questo trimmer a caldo per poter osservare il
comportamento al variare della luminosità ambientale di partenza.
A questo punto disponiamo di un sensore capace di rilevare la luminosità presente
nell’ambiente in cui si trova e di produrre, in conseguenza a questo, due tipi di segnali:
170
1. in caso di luminosità insufficiente, dove per insufficiente si intende la mancanza
di illuminazione diretta proveniente dall’attuatore, il sensore non invia nessun
segnale al microcontrollore, ma accende un led rosso di segnalazione;
2. In caso di luce accesa (quella del gruppo di illuminazione), il sensore invia un
segnale al pin dedicato del microcontrollore al quale è collegato.
Un altro aspetto considerato è quello legato all’alimentazione del circuito di feedback.
Dagli schemi precedenti è evidente che sono necessarie due tensioni:
•
5V per il TSL250 e per il ramo contente il led;
•
12V per i restanti componenti.
Per ottenere in modo agevole quello che serve, senza ovviamente aggiungere l’onere di
un alimentatore dedicato, abbiamo deciso di utilizzare la stessa alimentazione a 12V
utilizzata dal blocco di controllo, avendo pensato di posizionare tutti questi blocchi
funzionali vicini tra loro in una eventuale applicazione definitiva.
Figura 2.18. Circuito feedback lato saldature. La schematizzazione evidenzia i collegamenti che
realizzano l'alimentazione duale a 12V e 5V.
Quindi, si è ricorsi ad un semplice partitore di tensione resistivo per prelevare i 5V
dall’alimentazione principale, al fine di alimentare i componenti relativi, non essendoci
da parte di questi un eccessivo assorbimento di corrente, che provocherebbe la caduta
171
drastica della tensione al collegamento col partitore (come invece accadrebbe a livello
del circuito di controllo dove, per ottenere i 5V necessari, si è dovuti ricorrere al
LM7805).
Nelle
figure
sono
evidenziati
proprio
i
collegamenti
dedicati
all’alimentazione.
Si è quindi realizzato uno stadio di feedback in grado di discriminare il livello di
luminosità presente nell’ambiente e di comunicarne al microcontrollore le variazioni.
L’intelligenza del circuito di controllo smisterà questi dati verso l’host, capace, grazie
all’interfaccia customizzata di cui è dotato, di fornire all’utente un’informazione da lui
interpretabile.
172
8. FASE DI COLLAUDO
8.1 Assemblare il sistema
Nelle pagine che seguono, descriveremo le fasi di progetto riguardanti il collaudo
funzionale del prototipo realizzato. Dopo aver esaurientemente trattato tutte le parti
componenti, e le motivazioni delle scelte progettuali fatte, cercheremo di mettere
assieme i risultati raggiunti, verificando in che misura il sistema realizzato soddisfi
effettivamente le specifiche introdotte
All’inizio del lavoro siamo partiti dall’analisi della problematica proposta: si voleva
cioè realizzare un vero e proprio sistema domotico, concepito e realizzato
principalmente per un’utenza diversamente abile. Proprio per questo motivo, come
aspetto fondamentale è stato giudicato quello legato alla possibilità, da parte dell’utente,
di comunicare in modo efficace con il sistema stesso. Si doveva garantire che il soggetto
potesse interagire con il sistema di controllo, usufruendo appieno delle proprie abilità
residue, utilizzate in egual modo per captare il feedback proveniente dalle azioni
compiute dal sistema intelligente.
Un sistema come quello di cui si è prodotto il prototipo, può rappresentare un aiuto per
quei soggetti afflitti da gravi disabilità motorie o sensoriali, che non hanno la possibilità
di interagire con l’ambiente domestico, perché non dispongono delle attitudini sensoriali
o motorie, necessarie per interpretare gli input esterni. A questo scopo, l’intelligenza di
173
cui è dotato il sistema, insieme alla realizzazione personalizzata dell’interfaccia, esegue
uno switching di sensi, così da permettere all’utente di usufruire in modo cospicuo delle
proprie capacità. Proprio la vasta gamma di condizioni di disabilità possibili però, ha
costretto a ragionare sulla customizzazione del sistema. Per garantire che il sistema
fosse utilizzabile in un ampio numero di casi, se ne doveva amplificare l’universalità,
così da poter essere adattato ai casi più svariati.
Perciò, in questo capitolo, dopo aver descritto le fasi del montaggio che portano alla
costituzione di una prima soluzione prototipale di test, analizzeremo i risultati ottenuti,
compiendo un riesame del progetto, così da verificarne l’attinenza alle specifiche.
8.2 I Componenti
Come abbiamo ampiamente descritto nel capitolo precedente, l’applicazione realizzata,
che verrà composta di seguito, prevede l’utilizzo del sistema ausilio per il controllo
dell’illuminazione domestica. L’utente non dispone delle abilità necessarie a comandare
un azionamento standard e a ricevere quel feedback visivo che segnala proprio
l’accensione della luce. Le condizioni che impediscono l’’autosufficienza del soggetto
in un contesto come quello descritto, potrebbero essere legate ad una condizione di
grave disabilità visiva, di impossibilità nella deambulazione (paraplegia) o di
combinazione estremamente limitante delle due condizioni.
Rivisitiamo brevemente quali sono le parti principali che costituiscono il nostro sistema.
8.2.1 L’interfaccia
Il programma di interfaccia è stato ampiamente descritto nella prima sezione. Esso
permette all’host di comunicare bidirezionalmente col circuito di controllo gestendo con
esso uno scambio dati conforme al protocollo Wireless Lan (Wi-Fi). Ma l’interfaccia
non è composta solo dal software, ma anche dall’hardware con il quale si interagisce
fisicamente. Stiamo parlando dell’host che costituisce proprio la nostra Control Station,
il punto di controllo del sistema domotico. Sebbene sia possibile utilizzare a questo
scopo un generico personal computer con performance computazionali standard (a patto
di essere fornito di scheda per la connettività Wi-Fi ovviamente), in seconda analisi si è
174
pensato di utilizzare una macchina fornita di touch screen e che massimizzasse la
portabilità, così da semplificarne l’istallazione anche su un’ipotetica carrozzina per
disabili. L’oggetto, presente sul mercato, che sembra soddisfare a pieno le specifiche
richieste è l’ultra mobile PC Samsung Q1-Ultra.
Figura 8.1 Samsung Q1 Ultra
Questo Ultra mobile PC non possiede potenza di calcolo molto elevata, ma di gran
lunga sufficiente (800 MHz) per costituire a pieno titolo l’host del sistema, essendo
fornito di scheda per la connettività Wi-Fi. Il caratteristico touch pad lo rende
sicuramente accessibile per quella parte di utenza dotata di sufficiente mobilità degli arti
superiori. Ovviamente tutto questo non basta per renderlo compatibile con un’utenza
caratterizzata da significativa disabilità visiva. Per rendere pienamente fruibile il nostro
sistema ausilio ad utenti di questo tipo, si è deciso di aggiungere un’opportuna
interfaccia vocale. Questa funzionalità è fornita semplicemente da un software
reperibile in commercio: il Dragon Naturally Speaking della Scansoft. In realtà questo
SW si occupa principalmente di dettatura su comuni programmi di scrittura (Microsoft
Word, WordPad), ma può essere efficacemente utilizzato per impartire comandi vocali
al calcolatore (apri finestra, chiudi finestra, esegui).
175
Figura 8.2 Particolare dell'interfaccia con barra per il riconoscimento vocale attiva. La pressione del tasto
viene effettuata pronunciando LUCE
Per rendere funzionale l’interfaccia vocale, bisogna collegare al computer un semplice
microfono (integrato nel caso del Samsung Q1), e adempiere ad un semplice tutorial
durante il quale si viene guidati alla lettura di un breve brano, che permette
l’adattamanto del software ai propri parametri vocali salvati in un file apposito. Questo
garantirà un riconoscimento vocale efficace del momento dell’utilizzo. Nel nostro caso,
sarà sufficiente, una volta attivato il sw di interfaccia B-Serial, pronunciare il nome del
tasto che si vuole premere (che corrisponderà ad un determinato applicativo) per
ottenerne l’attivazione. In questo caso particolare l’utente dovrà pronunciare
semplicemente LUCE per inviare il comando all’attuatore. Per garantire all’utente
maggior consapevolezza, l’host viene equipaggiato con un software per la lettura dello
schermo, come JAWS, distribuito dalla Freedom Scientific, che effettua una lettura
della schermata, fornendo quindi informazione sul nome dei tasti presenti nel
programma di interfaccia.
176
Nell’ottica di rendere customizzabile un sistema come quello realizzato, di essere cioè
essere sagomato alle necessità particolari dell’utente, è utile considerare che, in
commercio, è disponibile una vasta gamma di sensori, capaci di captare molte tipologie
di input provenienti dal soggetto diversamente disabile. In questo modo è possibile
caratterizzare il sistema ausilio in base alle abilità disponibili, sfruttando l’universalità
che fortemente caratterizza il nostro sistema. I sitemi di input presenti in commercio
permettono di sfruttare una vasta gamma di abilità residue, dalla capacità di premere
pulsanti grandi e colorati, adatti a chi ha mantenuto solo movimenti grossolani, alla
possibilità di controllare l’attuatore tramite movimenti del mento o tramite il soffio.
Vediamone di seguito qualche esempio.
Interruttore a sfioramento. Permette l’interazione
tramite il soffio e il risucchio, utilizzato dagli utenti
affetti da grave tetraplegia che mantengono le funzioni
motorie del capo.
Interruttore
a
sfioramento.
Questo
interruttore
permette il controllo ad utenti che non sono in grado di
imprimere la forza necessaria per attivare un sensore
tipo tasto.
Interruttori a tasto. Permette l’interazione agli utenti
che non mantengono capacità motorie fini ,ma che
riescono a muovere, seppur in modo grossolano un
arto. Sono disponibili anche versioni a pedale.
177
Interruttori a pugno. Captano il segnale provocato
dalla stretta del pugno intorno al sensore stesso. Ideali
per soggetti che non dispongono di piena articolazione
dei movimenti della mano.
Per finire, il programma di interfaccia elabora i segnali provenienti dal circuito di
controllo fornendo all’utente il giusto segnale di ritorno, sfruttando la sintesi vocale
implementata al suo interno.
178
8.2.2 Il circuito di controllo
Anche questo blocco è stato ampiamente descritto in precedenza; riassumendone le
potenzialità diciamo che, grazie al microcontrollore della Microchip, rappresenta il
collegamento intelligente tra l’utente e l’attuatore. Riceve segnali dall’host sotto forma
di onde radio in base ai quali comanda l’attivazione del complesso di illuminazione
scelto come terminale dell’applicazione. È concepito in modo da captare il segnale
proveniente dallo stadio feedback e inviarlo alla Control Station che lo elabora e lo
presenta opportunamente all’utente. Tutte le funzioni appartenenti al circuito di
controllo provengono in prima analisi dallo strato firmware redatto ad hoc e caricato
opportunamente all’interno del PIC16F628.
Figura 8.3 Il circuito di controllo
8.2.3 Il modulo di conversione EZL
Per rendere effettiva la comunicazione senza fili, è stato installato sul circuito di
controllo un modulo dedicato presente in commercio che realizza la conversione tra lo
standard EIA RS-232, il protocollo di comunicazione sul quale si basa il circuito di
controllo, e lo standard IEEE 802.11b (Wireless LAN o Wi-Fi) che viene invece
utilizzato per collegare l’host agli apllicativi domotici.
L’uso dell’EZL-80c ha garantito, come appurato in fase di collaudo elevate prestazioni
sull’efficienza della connessione, rivelatasi molto stabile ed efficiente all’aumentare
179
della distanza tra terminali di trasmissione e all’interposizione di barriere
architettoniche (muri o solai).
Figura8.4 Il modulo EZL-80c
8.2.4 L’attuatore
A puro scopo dimostrativo, per realizzare l’attuatore domotico, è stata scelta una
normale lampada da tavolo. Questo ha permesso di dimostrare l’adattabilità e
l’universalità del circuito di controllo nei confronti di un oggetto comune nell’uso
quotidiano. Le modifiche necessarie riguardano, come detto in precedenza,
esclusivamente lo stadio di alimentazione della lampada.
Figura8.5 L'attuatore è una comune lampada da tavola alimentata con la rete
180
8.2.5 Lo stadio feedback
Il circuito di controllo deve disporre di segnali in ingresso legati all’attività della
lampada/attuatore, per poterne fornire traccia, in ultima analisi, all’utente. Per garantire
questo tipo di rapporto comunicativo, è stato improntato uno stadio circuitale, basato su
fotorilevatore, capace di trasformare il livello di luminosità presente nell’ambiente in
differenza di potenziale utilizzabile come Input dal microcontrollore. Il suddetto stadio
deve inoltre essere capace di discriminare il superamento di un dato livello di
riferimento, per garantire l’individuazione del momento in cui avviene l’accensione
della lampada controllata.
Figura8.6 Stadio Feedback a Fotorilevatore
8.3 L’assemblaggio
A questo punto si tratta di mettere insieme assemblandoli i blocchi realizzati,
componendo, in questo modo, il prototipo funzionale del sistema di ausilio domotico. Il
primo collegamento da improntare correttamente è quello tra circuito di controllo e
modulo di conversione. Nella sezione relativa, avevamo detto che il circuito a
181
microcontrollore era stato fornito di connettore DB9 complementare con quello presente
sull’EZL e che lo stesso era stato fatto per il pin-jack dell’alimentazione, così da
garantire la necessità di un singolo alimentatore a 12V per l’intero blocco ControlloConvertitore. Proprio queste due connessioni forniscono, oltre al necessario
collegamento funzionale, il supporto meccanico sufficiente alla realizzazione di una
soluzione prototipale. È necessario a questo proposito dire che, in una fase di sviluppo
successiva, il modulo EZL-80c, privato del kit applicativo EZL-90, potrà essere
integrato direttamente allo stadio del microcontrollore, garantendo una notevole
riduzione delle dimensioni del blocco di controllo e l’annessione della connettività WiFi allo stesso.
Figura8.7 Il connettore DB9 e il pin d'alimentazione collegano i due blocchi
Una volta realizzata la connessione tra i due blocchi, avremo ottenuto una versione WiFi del circuito di controllo, potendo quindi procedere con una prima fase di testing della
comunicazione wireless. A questo scopo, il blocco è stato alimentato ed è stata
improntato il collegamento con l’host. Per prima cosa, avendo cura di attivare la scheda
Wi-Fi del computer utilizzato da stazione di controllo, si procede all’individuazione
della rete wireless relativa al circuito di controllo.
182
Figura 8.8 La connessione punto - punto col circuito di controllo viene individuata tra quelle disponibili
Se dal menu Start di Windows accediamo alle Reti senza fili, il SO ricerca in modo
automatico le reti wireless presenti e, se i collegamenti sono stati effettuati in modo
corretto, apparirà la rete Test (il nome era stato associato alla connessione in fase di
setting del convertitore Ezl, vedi capitolo dedicato) tramite la quale sarà possibile
stabilire una connessione punto-punto (ad hoc) con il device di controllo.
Figura 8.9 L'host connesso al blocco di controllo Wi-Fi
In questo modo si accede alla rete Wi-Fi fornita dal convertitore della Sollae; rimane
solo da stabilire una effettiva connessione tra il blocco ottenuto dall’assemblaggio e
l’host. Per una semplice verifica di comunicazione, possiamo utilizzare il tool di test
incluso nel software ezConfig con il quale riusciamo ad inviare e a ricevere pacchetti al
183
circuito di controllo, verificando in questo modo la genuinità della connessione stabilita
via onde radio.
Figura 8.10 La schermata di prova del sw ezlConfig
Appurato che il blocco di controllo funzioni correttamente e che la comunicazione
senza fili con la stazione di controllo sia stabile, si può procedere ad assemblare lo
stadio feedback e la parte relativa all’attuatore. Le prime connessioni da realizzare sono
sicuramente quelle legate all’alimentazione dei diversi blocchi. Come è stato detto in
precedenza, le scelte progettuali e realizzative hanno portato verso un processo di
unificazione delle alimentazioni. Questo approccio favorisce il contenimento dei costi,
minimizzando il numero degli alimentatori necessari e riducendo al minimo il numero
di accessi alla rete di alimentazione. Ricordando comunque che lo stadio di sviluppo è
ancora a livello prototipale, vediamo nella figura seguente le connessioni che
permettono collegare circuito di controllo, lo stadio di applicazione e lo stadio feedback.
184
Figura 8.11 I collegamenti tra gli stadi dell'applicazione
Figura 8.12 L'attuatore assemblato
Dopo aver collegato i diversi stadi, si può procedere al collaudo vero e proprio. Quindi
tramite il programma di interfaccia si verifica il controllo sul dispositivo domotico,
rappresentato, nel caso, specifico dalla lampada da tavolo.
185
Figura 8.13 L'interfaccia e l'attuatore sono collegati dal ponte radio Wi-Fi
Figura 8.14 La soluzione col Samsug Q1
Il sistema assemblato ha dimostrato di funzionare perfettamente al variare della
posizione della Control Station, pensata proprio per essere abbastanza portatile da poter
essere installata su di una carrozzina. Il raggio d’azione del Wi-Fi (arriva fino a 100m)
garantisce piena mobilità da parte dell’utente, senza che vengano pregiudicate le
performance del sistema ausilio. L’aggiunta del comando vocale permette poi di rendere
ottimali le caratteristiche di accessibilità dell’interfaccia. In aggiunta a questo, il ritorno
vocale, prodotto dall’interfaccia nel momento in cui capta il segnale proveniente
186
dall’attuatore, fornisce un opportuno ritorno all’utente che, non disponendo dei sensi o
delle capacità motorie necessarie ad acquisire consapevolezza delle proprie azioni,
sfrutta in questo caso l’udito per apprendere che l’azionamento sia andato a buon fine (il
messaggio della sintesi vocale dice proprio la luce è accesa )
187
CONCLUSIONI
Il nostro lavoro è stato intrapreso con lo scopo di realizzare un sistema innovativo che
potesse rispondere alle esigenze particolari di un’utenza disabile. La collaborazione con
la B-Able s.r.l., azienda nata proprio con l’intento di sviluppare nuove soluzioni ad
elevato contenuto tecnologico nell’ambito dell’AssistiveTechnology, ha portato alla
formalizzazione del seguente scenario.
Era necessario improntare la realizzazione di un vero e proprio sistema ausilio, in grado
di aumentare l’indipendenza di utenti diversamente abili nel controllo di applicativi
domotici, presenti nell’ambiente domestico. A questo scopo, risultava di vitale
importanza che il sistema concepito mantenesse come requisito principale, quello di
costituire un mezzo, tramite il quale venissero sfruttate le abilità residue del soggetto,
sia in fase di controllo che di monitoraggio degli applicativi comandati.
Nell’introduzione, infatti, ci chiedevamo come sarebbe stato possibile controllare una
qualsiasi applicazione senza la possibilità o meglio, l’abilità, di averne coscienza. Il
sistema ausilio deve perciò necessariamente fornire uno switching sensoriale adeguato,
così da garantire al soggetto informazioni sul controllo, in una forma da lui
comprensibile: un segnale visivo per un non udente, sonoro o tattile per non vedenti o
paraplegici etc. Il numero estremamente elevato di situazioni particolari ci ha portato ad
un’importante riflessione: il sistema doveva presentare una piattaforma universale per
182
venire
customizzato a seconda delle abilità utilizzabili dall’utente. L’universalità
doveva essere garantita anche per il controllo, permettendo l’utilizzo del medesimo
sistema per i diversi attuatori domotici presenti nell’ambiente domestico (azionamenti
per porte, serrande, sistemi di controllo dell’illuminazione, etc.). Un altro aspetto
importante era quello di pensare al dispositivo come facilmente installabile ed
utilizzabile, e di conservare caratteristiche capaci di garantire al sistema un basso costo.
Un sistema di questo tipo doveva per forza essere composto di diversi blocchi,
interconnessi in modo funzionale tra loro, che potessero inoltre costituire un
collegamento consono tra l’utente e l’ambiente circostante. Tra i suddetti blocchi
ricordiamo:
•
Un’interfaccia utente, capace di permettere all’utente di controllare l’intero
sistema in modo consono;
•
uno stadio di controllo in grado di captare segnali provenienti dall’interfaccia e
quindi dall’utente, di controllare di conseguenza lo strato applicativo e di
riceverne feedback destinati all’utente;
•
un sistema di comunicazione capace di collegare i due blocchi precedenti;
•
Il blocco applicativo, che è caratterizzato in base all’attuatore che si vuole
controllare;
•
Lo stadio di feedback, appositamente realizzato, capace di segnalare allo stadio
di controllo l’attivazione, o la mancata attivazione dell’applicativo controllato.
Tutti questi blocchi, connessi tra loro e all’utente tramite l’interfaccia, costituiscono un
sistema ausilio conforme alle specifiche.
Lo stadio di controllo deve, prima di tutto, essere sicuramente dotato di uno strato
logico adeguatamente programmato. A questo scopo, tutta la progettazione è stata
basata su un microcontrollore, in particolare su un PIC della Microchip, caratterizzato
da un’estrema reperibilità sul mercato (che gli garantisce bassissimo costo anche al
dettaglio) e agevole programmazione. Tramite l’IDE MPLAB, fornito gratuitamente
dalla stessa casa produttrice, è stato possibile realizzare un firmware dedicato, tramite il
quale il microcontrollore è stato programmato ad eseguire le funzioni richieste. Nello
specifico, il PIC16F628, scelto per la program memory di tipo flash riprogrammabile,
per il basso costo e per l’hardware integrato al suo interno, è stato improntato per una
183
comunicazione seriale con l’host di interfaccia utente e con lo stadio di applicazione.
Grazie al firmware redatto in C, il PIC è in grado di ricevere un messaggio seriale dal
programma di interfaccia e di produrre, in corrispondenza di quest’evento, un output di
controllo sull’applicativo. Il codice sorgente impone al PIC stesso, inoltre, di ricevere
un input opportuno dallo stadio di feedback, e di inviare a sua volta un messaggio
seriale all’host, così da fornire un contenuto informativo, interpretabile dall’utente
grazie all’interfaccia customizzata, sullo stato dell’ambiente circostante dopo
l’attivazione dell’applicazione.
Il protocollo scelto per la comunicazione tra stadio di interfaccia e di controllo è l’EIARS232. Abbiamo visto come in un primo momento, l’attenzione era volta verso l’USB,
sicuramente più portabile e reperibile sulle moderne macchine, ma non altrettanto
versatile per quanto riguarda la realizzazione di un device ex novo. In questo caso,
infatti, si sarebbe rivelato necessario redigere un driver dedicato (compito senza dubbio
arduo e di scarso interesse per il lavoro proposto), affinché il SO potesse riconoscere il
dispositivo collegato. Per ovviare a questa problematica si è perciò preferito rivolgere
l’attenzione verso l’RS-232, che garantiva maggior semplicità di utilizzo in una
circostanza del genere. Va aggiunto a questo che il PIC scelto, integra al suo interno un
modulo USART dedicato ad una comunicazione seriale di questo tipo.
Una volta redatto e debuggato il codice sorgente, abbiamo proceduto ad una fase di
testing dello stesso (utilizzando i tool appositi dell’ide della Microchip), con la quale
determinare il corretto funzionamento del software.
La fase successiva è stata la vera e propria realizzazione hardware di un prototipo
funzionante dello stadio di controllo in tutti gli aspetti necessari ad un corretto, seppur
prototipale, funzionamento.
I primi componenti assemblati sono stati quelli dedicati alla comunicazione seriale. Per
questo motivo tra il microcontrollore e il connettore DB9 è stato interposto un integrato,
il MAX232 della Maxim, che realizza il necessario adattamento tra i livelli di tensione
propri della logica TTL lato PIC (3.5-5 V) e quelli utilizzati dal protocollo utilizzato
(+/-12 V).
L’aspetto successivo riguardava la possibilità di controllare un applicativo alimentato
dalla rete tramite lo stadio di uscita del PIC. Per realizzare il controllo è stato scelto un
BJT che funzionasse da interruttore, switchando tra lo stato di interdizione e quello di
saturazione, al fine di controllare un relais collegato all’alimentazione dell’attuatore.
184
Tramite il corretto dimensionamento dei componenti resistivi, la corrente erogata dallo
stadio di uscita del microcontrollore, veniva amplificata opportunamente, così da poter
raggiungere un valore adeguato all’eccitazione della bobina del relais.
Per quanto riguarda l’alimentazione, il problema principale è stato quello di
minimizzarne il numero, così da realizzare, anche in fase di prototipo, un hardware non
necessitante di troppi alimentatori per il suo funzionamento. In questo senso, usare
l’LM7805 ha permesso di collegare lo stadio di controllo ad un comune alimentatore
stabilizzato a 12V 1A max, ottenendo dal regolatore i 5V utilizzati negli stadi che
richiedevano un tale voltaggio.
Lo stadio di interfaccia ha richiesto la redazione, in Visual Basic 6, di software
dedicato, capace di trasformare l’host, utilizzato dall’utente, in una vera e propria
control station che interagisce con gli applicativi domotici. Proprio l’interfaccia deve
subire le necessarie customizzazioni relative al tipo e al grado di disabilità presenti
nell’utente. Nello specifico, l’applicazione alla quale ci siamo dedicati, riguardava la
possibilità, da parte di soggetti non vedenti o gravemente limitati nei movimenti, di
accendere un gruppo di luci tramite comando vocale o tattile, e di ricevere feedback
sonoro
(sotto
forma
di
comunicazione verbale computerizzata) sullo stato
dell’illuminazione stessa.
A questo scopo, l’interfaccia doveva essere assai comprensibile ed immediata da
utilizzare, giustificando la scelta di suddividere lo schermo del personal computer in
quattro aree, destinate eventualmente al controllo di altrettanti attuatori. L’idea infatti è
quella di controllare non uno, ma un gruppo di applicativi così da rendere
effettivamente indipendente la persona diversamente abile nel compiere quei semplici
gesti della vita quotidiana, resi più ardui se si presenta una condizione di disabilità.
Per rendere effettiva la comunicazione tra host e stadio di controllo sono stati utilizzati
degli appositi controlli di VB, in grado di implementare sia una comunicazione seriale
che LAN tra i blocchi. In questo modo, il SW è pienamente capace di comandare lo
stadio di controllo, e di ricevere da questo informazioni destinate all’utente.
Rimanendo possibile aggiungere all’host tutta una serie di sensori, reperibili in
commercio, capaci di sfruttare appieno le abilità residue dell’utente, nel caso specifico,
per implementare il comando vocale è stato aggiunto un software commerciale. Il
Dragon Naturally speaking è fondamentalmente un programma di dettatura, ma si è
185
rilevato molto funzionale anche per impartire comandi alla Control Station, dato il
layout del programma di interfaccia.
Mentre quindi lo stadio applicativo è rappresentato da una normale lampada domestica
alimentata dalla rete (salvo alcune modifiche effettuate per il collegamento), lo stadio
feedback ha richiesto una fase progettuale dedicata. Dovendo rilevare il livello di
luminosità da comunicare all’utente, ci siamo basati su un fotorilevatore della Texas
Instruments, il TSL250, hardwerizzato in una soluzione circuitale opportuna, che ci ha
permesso di interpretare in modo soddisfacente la luminosità presente nell’ambiente,
così da individuare efficacemente l’accensione del gruppo luminoso controllato,
producendo un feedback destinato all’interfaccia e quindi all’utente.
Restava da realizzare il sistema di comunicazione. Sebbene avessimo già scelto il
protocollo RS-232 come mezzo di comunicazione tra host e controllo (PIC), in un
secondo momento abbiamo ritenuto opportuno sciogliere il sistema dai vincoli
provenienti da collegamenti wired. A questo scopo era necessario l’interfaccia e lo
stadio di controllo fossero collegati da un protocollo wireless, senza che questo
modificasse le funzioni del sistema. Per questo motivo si è ricorsi ad un convertitore
RS-232/Wi-Fi prodotto dalla Sollae System: l’EZL-80c.
L’utilizzo di questo convertitore (economico e di semplice installazione e
configurazione) ha permesso di mantenere inalterati gli stadi realizzati precedentemente,
salvaguardando le opportune richieste di minimizzazione dei costi in fase prototipale,
restando la realizzazione di un dispositivo wireless ex novo non di interesse per il
lavoro sviluppato.
Al termine di questo lavoro siamo quindi arrivati alla realizzazione completa di un
sistema, seppur in uno stadio ancora prototipale, che permette all’utente di ottenere il
controllo domotico dell’abitazione (luci, azionamento di porte, finestre, serrande) e di
ricevere un’informazione di ritorno dimensionata sulle sue abilità e particolarità legate
alla sua situazione fisica. Il sistema ha mantenuto in questa fase dei costi estremamente
contenuti. Tutti i componenti sono largamente presenti in commercio con prezzi
pienamente accessibili (il PIC costa pochi euro mentre il convertitore EZL ne costa
poche decine), mentre il passaggio al wireless ha permesso di rispettare la specifica
relativa alla facile installabilità. In quest’ottica, anche il programma di interfaccia,
sostanzialmente una Windows like application, permette di utilizzare un comune
personal computer come host, rendendolo la stazione di controllo del sistema.
186
Sviluppi futuri
La prima considerazione sullo sviluppo futuro del sistema ausilio, sarà sicuramente
legato al normale processo evolutivo a cui ogni prototipo va incontro, prima di arrivare
a costituire per lo meno una β-version. A questo scopo, in prima istanza, si dovrà
sicuramente procedere all’integrazione del modulo di conversione EZL all’interno del
circuito di controllo. Per fare ciò sarà senza dubbio necessario disfarsi del supporto di
sviluppo EZL-90, assai più ingombrante del nucleo di conversione vero e proprio, e che
fornisce solo funzionalità legate al cablaggio del connettore DB-9 e dell’alimentazione.
Altro aspetto legato alla fase di sviluppo, sarà sicuramente la miniaturizzazione della
componentistica hardware realizzata e lo sviluppo strutturale, così da costituire un
dispositivo in grado di avvicinarsi in modo significativo al prodotto finale, se non altro
al fine di pianificare le strategie legate all’installazione.
L’ottimizzazione dell’alimentazione sarà sicuramente un aspetto importante nel
garantire al sistema un minimale cablaggio di cavi. L’idea è infatti quella di aggiungere
un trasformatore interno all’hardware, cercando di non inficiare sulla compattezza del
pezzo, così da rendere possibile l’alimentazione dello stadio di controllo direttamente
dalla rete. Una caratteristica del genere non costituirebbe comunque una modifica
fondamentale del funzionamento del dispositivo.
Diciamo quindi che, bisognerà investire il giusto tempo uomo per intraprendere una
giusta fase di sviluppo post-prototipo.
Per quanto riguarda l’applicazione del sistema, in futuro si procederà senza dubbio
all’applicazione dei risultati ottenuti anche ad altri tipi di attuatori (con relativo stadio di
feedback personalizzato), così da sfruttare le caratteristiche di network della rete, grazie
all’utilizzo di un router Wi-Fi. Altro aspetto da sviluppare sarà inevitabilmente quello
legato alla customizzazione dell’interfaccia, in base alle diverse condizioni in cui versa
l’utente. A questo scopo sarà utile pensare a sensori capaci di tracciare il movimento del
soggetto, così da permettere l’interazione anche con movimenti permessi minimi.
Per ultimo, sarebbe interessante sviluppare uno stadio di feedback non a riconoscimento
di soglie, come quello caratterizzato per l’applicazione descritta, ma a incremento
differenziale. In questo modo, il sistema sarebbe capace di riconoscere come segnale
utile non il superamento di una soglia, che nel caso della luminosità potrebbe verificarsi
187
anche in condizioni slegate dall’accensione del gruppo luminoso controllato, ma
l’incremento della luminosità di un certo valore, indipendentemente dal valore di
partenza. Questo permetterebbe un comportamento più simile a quello dell’apparato
sensoriale umano, scindendo il riconoscimento dalle condizioni iniziali, supposte
variabili.
Con lo sviluppo quindi di interfacce sempre più caratterizzate e col controllo di attuatori
diversi, reso peraltro agevole dalle ben note caratteristiche di universalità della
piattaforma di controllo, sarà possibile realizzare un vero e proprio sistema casa
integrato pensato appositamente per persone diversamente abili, capaci di sfruttare
l’ausilio tecnologico al fine di incrementare la propria autonomia, verso una vita più
inclusiva.
188
BIBLIOGRAFIA
[1] Hoogerwerf J., Linsey A., Bitelli C. Progetto Europeo BRIDDGE: assistite
technology against social exclusion. AIA Bologna 2002.
[2] Andronico S., Bitelli C., Gamberoni F. Gli ausili tecnologici una meta possibile.
La rete dei centri Italiani. Bologna 2004.
[3] Bitelli C, Costa C. Le nuove tecnologie per disabili motori tratto da Cliccando
cliccando: tecnologie multimediali per l’Handicap. Provveditorato agli studi di
Bologna, sett 2000.
[4] PiC Microchip. Disponibile presso www.microchip.com. Ultima consultazione
Ottobre 2008
[5] Tanzilli S. PIC by example. Disponibile presso www.tanzilli.com. Ultima
consultazione Ottobre 2008.
[6] PIC16F628, PIC16F84 Microchip microcontrollers. Datasheet disponibile presso
www.microchip.com. Ultima consultazione Ottobre 2008.
[7] Specifiche USB, disponibile presso wwwUSB.org. Ultima consultazione Ottobre
2008.
[8] Hyde J. USB designed by example. A practicle guide to building I/O device. 2002
[9] Axelson J., USB Complete. Giugno 2001. Disponibile su www.lvr.com. Ultima
consultazione Ottobre 2008.
[10] EIA RS-232 electrical parameters. Disponibile presso www.wikipedia.com.
Ultima consultazione Ottobre 2008.
[11] Fondamenti sugli standard di interfaccia EIA RS-232 e IEEE-488. GMEE
(Gruppo di misure elettriche ed elettroniche) Università di Padova. Disponibile
presso www.dei.unipd.it/ricerca/gmee.
[12] Sciuto D., Buonanno G., Fornaciari W. Introduzione ai sistemi informatici.
McGrawHill. 2000.
[13] EZL 80c User’s Manual. Manuale disponibile presso www.sollae.com. Ultima
consultazione Ottobre 2008.
[14] EZL 90 User’s Manual. Manuale disponibile presso www.sollae.com. Ultima
consultazione Ottobre 2008.
[15] MAX232, MAX232I Dual EIA-232 DRIVERS/RECEIVERS. Datasheet disponibile
presso www.maxim.com. Ultima consultazione Ottobre 2008.
[16] Relays Finder 40 series. Miniature P.C.B. relays 8-10-16 A. Datasheet disponibile
presso www.findernet.com. Ultima consultazione Ottobre 2008.
[17] 2N1613-2N1711. Switches and universal amplifiers. Datasheet disponibile presso
www.st.com. Ultima consultazione Ottobre 2008.
[18] MC78XX, LM78XX, MC78XXA 3 terminal 1A Positive Voltage Regulator.
Datasheet disponibile presso www.fairchildsemi.com. Ultima consultazione
Ottobre 2008.
[19] Bradley J., Millspaugh A. Visual Basic 6.0 guida alla programmazione. McGrawHill 2000.
[20] LIBRO BIANCO DELLA DOMOTICA. Cap 1-2-4-7. A cura di domocenter,
Centro servizi per l’innovazione, Provincia di Modena.2005.
[21] Sistema Myhome. Disponibile presso www.bticino.it. Ultima consultazione
Ottobre 2008.
[22] TSL250, TSL251, TSL252 light-to-voltage optical sensors. Datasheet disponibile
presso: www.ti.com. Ultima consultazione Ottobre 2008.
[23] LM111, LM211, LM311, Voltage comparator. Datasheet disponibile presso
www.national.com. Ultima consultazione Ottobre 2008.
RINGRAZIAMENTI
Giunto al termine di questo lavoro, desidero ringraziare ed esprimere la mia
riconoscenza nei confronti di tutte le persone che, in diversi modi, mi sono state vicine e
hanno permesso e incoraggiato sia i miei studi che la realizzazione e la stesura di questa
tesi. I miei più sentiti ringraziamenti vanno a chi mi ha seguito durante la redazione di
questo lavoro:
ƒ
Al Prof. Nicola Rosato, per i consigli tramite i quali mi ha aiutato ad
intraprendere le scelte più appropriate.
ƒ
All’Ing. Paolo Abundo, per l’amicizia, per la disponibilità e per la prontezza
dimostrata nell’offrire chiarimenti e suggerimenti, tramite i quali mi ha aiutato a
terminare questo percorso formativo.
ƒ
All’Ing Stefano Gelli della B-Able s.r.l. e ai suoi soci, l’Ing Fausto Davoli e il
Dr. Matteo Rugiano, va un ringraziamento speciale per aver contribuito in modo
decisivo alla mia crescita in sia in campo umano che professionale.
Per ultimi, ma di certo non per importanza, ringrazio la mia famiglia, gli amici e i
colleghi di lavoro, che mi sono stati vicini in tutti questi anni da studente, e che, oltre ad
avermi supportato, mi hanno più di tutto sopportato:
ƒ
Il primo pensiero va ai miei genitori, Giuseppe Rizzo e Angela Margherita
Picone. Senza il loro aiuto non avrei mai raggiunto questa meta. Sono davvero
grato per tutto il sostegno datomi, sperando che tutti i sacrifici spesi possano
essere in questo modo, almeno in parte, ripagati.
ƒ
Ringrazio in modo speciale mia sorella, Angela Rizzo, e Stefano Vernarecci,
per essersi sempre dimostrati fonte di esperienza e consigli, con i quali hanno
saputo rendere più chiara la strada davanti a me.
ƒ
Un pensiero speciale a Giovanni e Maria, amici e zii, sempre presenti con
parole amorevoli e sincere. Un bacio ai piccoli Elena e Matteo.
Come non ringraziare tutti i miei amici, sempre vicini e pronti a sostenermi, nei
momenti duri, con le loro parole e con i loro sorrisi, aiutandomi a credere in me stesso.
ƒ
In particolare ringrazio: Alessandro (Decky), Cristiano, Dario, Davide, Diego,
Francesco, Gianluca, Mattia, Paolo e Valerio. A voi tutti, pace amore e gioia
infinita.
Desidero ringraziare tutte le persone con cui ho iniziato e trascorso questi anni di studio,
con cui ho scambiato qualche pensiero o qualche idea. Un ringraziamento particolare a
Pamela Rammauro, collega di studi e di fatiche infinite, alla fine comunque sempre
superate.
Un ringraziamento ai maestri Mimmo e Stefano, i miei padri nella boxe.
Un pensiero e un ringraziamento sincero a tutti i colleghi di Ciampino e in particolare
alla squadra del Ricevimento e degli Ordini. Per aver reso molto meno fredde tante
mattine d’inverno. Grazie ragazzi, siete stati molto più che compagni di lavoro.
L’ultimo pensiero e ringraziamento va alla persona senza la quale, semplicemente,
niente sarebbe stato e sarà mai possibile. Ringrazio la mia Valentina per aver sempre
creduto in me senza riserve, e per avermi appoggiato in ogni momento di questo lungo
percorso.
Grazie di cuore a tutti.
Novembre 2008
Rizzo