Progetto INDOLE
annuncio pubblicitario
Progetto INDOLE
Pagina 1 di 30
Innovative Domotics for Living and Entertainment
Descrizione delle attività svolte
CUBIT-PSM-AIDILAB
Deliverable – D 3.2
Firmware/Software di controllo e gestione
Revisione
Data
Modifica
Redatta
Verificata
001
22-10-2013
Primo rilascio
CUBIT-PSM-AIDILAB
PSM
002
10-12-2013
Revisione e approvazione
CUBIT-PSM-AIDILAB
PSM
Rilascio Report finale – Revisione e
approvazione
CUBIT-PSM-AIDLAB
PSM
003
28-02-2014
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 2 di 30
Sommario
1 - Introduzione ................................................................................................................................................. 3
1 - Test hardware e firmware della ciabatta intelligente .................................................................................. 4
1.1 Componenti utilizzati............................................................................................................................... 4
1.2 Verifiche hardware effettuate ................................................................................................................. 4
1.3 Verifica corto circuiti ............................................................................................................................... 5
1.4 Verifica alimentazioni .............................................................................................................................. 6
1.5 Verifiche software effettuate .................................................................................................................. 7
1.6 Risultato dei test .................................................................................................................................... 12
2 - Software applicativo per Ciabatta .............................................................................................................. 13
2.1 Metrology Engine .................................................................................................................................. 14
2.2 Diagramma stati logici ........................................................................................................................... 16
2.3 Descrizione del firmware ....................................................................................................................... 17
3- Software applicativo per scheda Sensori INDOLE ....................................................................................... 21
3.1 Diagramma stati logici ........................................................................................................................... 22
3.2 Descrizione del firmware ....................................................................................................................... 23
4 – Sistema operativo: Android 4.2.2 kernel Linux 3.2.0................................................................................. 27
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 3 di 30
1 - Introduzione
Il presente Deliverable è il risultato della conclusione dell’Attività 3.2 - Realizzazione del software di controllo
e gestione comprendente anche i risultati dell’Attività 2.5 Progettazione del Firmware e Software di gestione
e integrazione delle componenti Hardware.
La prima parte fornisce la descrizione del Firmware di controllo e gestione, inclusi i test effettuati per ottenere
i requisiti per l’integrazione delle componenti Hardware e Firmware e i componenti utilizzati. Si forniscono
inoltre le descrizioni del software applicativo per la Ciabatta intelligente e del software applicativo per la
Scheda dei sensori INDOLE.
La seconda parte del Deliverable descrive il porting del kernek di Android su CPU Sitara che controlla la scheda
Engine.
Il presente Deliverable è stato realizzato dal personale dell’azienda CUBIT, PSM e AIDILAB.
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 4 di 30
1 - Test hardware e firmware della ciabatta intelligente
1.1 Componenti utilizzati
I dispostivi HW utilizzati per effettuare i test necessari sono descritti di seguito.
1. Oscilloscopio
L'Oscilloscopio utilizzato per effettuare le varie misurazioni è il LeCroy 24Xs-A 200MHz 2.5Gs/s
2. Alimentazione
Alimentazione da rete elettrica 220V AC
3. Multimetro
Il Multimetro utilizzato per misurare le varie tensioni è: il Fluke 87V
I dispositivi SW utilizzati per effettuare i test necessari sono descritti di seguito.
4. Power Line Modem ST7540 demostration Kit
Per i test di scambio dati abbiamo utilizzato il sw della evaluation board di ST.
1.2 Verifiche hardware effettuate
Errori sugli schemi elettrici e PCB
Nello schema elettrico 71023100_3 non è presente il nodo di collegamento tra C31-R23-pin3 di D9. Nei
prototipi abbiamo saldato tramite un filo i due punti.
FIGURA 1 - NODO DI PAOUT
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 5 di 30
Durante i test della board abbiamo visto che per scrivere nel control register del componente ST7540 è
necessario collegare anche il segnale CLR/T presente sul pin 8. Questo segnale deve essere anche collegato
al micro EM783 tramite optoisolatore HCPL-260L.
FIGURA 2 - PIN 8 DI U1 CLR/T
Errato componente U3. Sui prototipi è stato sostituito con un TLV1117_3V3.
FIGURA 3 –TLV1117_3V3
1.3 Verifica corto circuiti
Non sono risultati corto circuiti tra le alimentazioni e altre net.
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 6 di 30
1.4 Verifica alimentazioni
Verifica tensione 3V3H e VREF
Per eseguire un primo debug in sicurezza della ciabatta è stata staccata la parte in alta tensione della scheda.
Per alimentare il resto del circuito è stato utilizzato un alimentatore AC/DC esterno da 12V collegato tra il pin
3 di U3 e massa dissaldando R3 (figura 4).
Sono state verificate le seguenti alimentazioni:
3V3H: alimentazione a 3.3V creata dal componente U3 TLV1117,
test
VREF: tensione da 1.65V utilizzata per le letture ADC del micro EM783-MC3, test
--->3.308
--->1.664
Verifica tensione 12V e 5V
Le tensioni ISOLATE 12V e 5V utilizzate per le tre porte USB della ciabatta, sono state verificate dopo aver
dissaldato le resistenze R1(220VAC_LINE), R72(220VAC_NEUTRAL) e R13(VMON) e i condensatori C41, C46,
C50, C48, C59 e C54 dalla scheda. Anche queste modifiche sono state fatte per seguire un debug sicuro della
scheda, in quanto la tensione di rete 220V entra solo nell’alimentatore XP Power che genera il 12V.
Sono state verificate le seguenti alimentazioni:
12V: alimentazione a 12V creata da XP Power (P1),
5V: tensione a 5V creata da U1 a partire dal 12V,
test
test
FIGURA 4 –MODIFICHE PER VERICA TENSIONI
--->11.96
--->4.985
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 7 di 30
Verifica tensione 12VH
Per verificare il funzionamento del componente TEA1721xT che crea la tensione 12VH a partire dalla tensione
di rete 220V è necessario risaldare sulla scheda le resistenze R1 e R72.
Le prove hanno verificato il corretto funzionamento del TEA1721, anche se sono stati cambiati alcuni
componenti del circuito al fine di ottimizzare il setup time del 12VH.
12VH: alimentazione a 12V creata dal TEA1721,
test
--->11.96
Verificato il 12VH è stata risaldata sul circuito la resistenza R3 in modo da collegare il 12VH stesso al
regolatore di tensione U3 che genera il 3V3H necessario per alimentare il microcontrollore della ciabatta.
3V3H: tensione a 3.3V creata da U3 a partire dal 12VH,
test
--->3.305
Verifica funzionamento Relay
È stato verificato il corretto funzionamento dei relay bistabili RT314F12 K1, K2 e K3 sia con e senza carico.
1.5 Verifiche software effettuate
Microcontrollore EM783-MC3
La prima programmazione del micro EM783-MC3 deve essere fatta tramite comunicazione seriale utilizzando
il tool di sviluppo NXP Flash Magic. Per programmare la scheda è necessario:
Filare dalla scheda un connettore a tre poli con GND, RX e TX. Nota: importante mantenere l’ordine
indicato del tre segnali.
Chiudere il jumper di boot JP2 e alimentare la scheda. Questo fa si che il micro vada nella particolare
configurazione di boot HW via seriale.
Utilizzare un convertitore USB/seriale TTL per collegare il PC al connettore seriale a tre poli della
ciabatta.
Aprire Flash Magic Tool, caricare il file .hex del programma da flashare e impostare le caratteristiche
della seriale e di programmazione come da foto. L’ambiente di sviluppo utilizzato per compilare il
software per il micro EM783-MC3 è l’IDE Keil uVision5.
FIGURA 5 - PING SESSION
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 8 di 30
Una volta caricato il software è possibile programmare la scheda utilizzando il debugger jlink2 tramite
header P5.
Per verificare il funzionamento delle periferiche del micro è stato realizzato un programma di test che utilizza
il tool VirtualLCD come terminale video+tastiera della ciabatta. La comunicazione tra scheda e PC è realizzata
con la stessa interfaccia seriale utilizzata per programmare il microcontrollore.
FIGURA 6 – PROGRAMMA DI TEST
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 9 di 30
FIGURA 7 – PROGRAMMA DI TEST
Per simulare i segnali di consumo provenienti dalle tre utenze della ciabatta è stato utilizzato un generatore
di segnale sinusoidale a 50Hz. Il segnale prodotto è stato collegato sui condensatori di disaccoppiamento
(C41, C46, C50, C48, C59 e C54) messi prima degli amplificatori di segnale U12, U14 e U16.
FIGURA 8 – FRONT-END ANALOGICO
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 10 di
30
Andando a modificare l’ampiezza picco-picco della sinusoide prodotta dal generatore si riesce a valutare il
comportamento dei segnali di HIGHGAIN e LOWGAIN utilizzati dal micro EM783 per stimare il consumo di
corrente delle utenze tramite la sua interfaccia di Metrology Engine.
Il Metrology Engine rappresenta l‘interfaccia analogica del microprocessore EM783 ed è in grado di eseguire
misurazioni di tensione e corrente periodiche a partire dagli ingressi analogici di I_HIGHGAIN, VOLTAGE e
I_LOWGAIN.
Per avere misure accurate si devono utilizzare entrambi i canali HIGH e LOWGAIN. Il metrology in questo caso
validerà la lettura eseguita sul pin di I_HIGHGAIN per gli assorbimenti più bassi (figura 9), mentre validerà
quella su I_LOWGAIN per i consumi più alti (figura 10). Le figure seguenti mostrano in blu e giallo
rispettivamente l’andamento dei segnali LOWGAIN e HIGHGAIN.
FIGURA 9 – VALORE CORRETTO DA HIGHGAIN
FIGURA 10 – VALORE CORRETTO DA LOWGAIN
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 11 di
30
Power Line Modem
Per poter testare il collegamento del Power Line Modem abbiamo utilizzato il software della demo board di
STMicroelectronics, scambiando pacchetti tra l'evaluation board e la scheda della ciabatta intelligente.
I test effettuati sono stati di PING tra le due schede e TX/RX di pacchetti con risultati ottimi ( errore di perdita
del pacchetto intorno al 2% ).Nelle figure successive è possibile vedere i settaggi e i test effettuati.
FIGURA 11 - PING SESSION
FIGURA 12 - RECEIVING SESSION
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 12 di
30
FIGURA 13 - TRANSIMISSION SESSION
1.6 Risultato dei test
I risultati dei test evidenziano il problema HW del pin 8 di U6 da modificare sulla release successiva del
progetto e un ottimizzazione da fare sul circuito del TEA1721 per velocizzare lo startup timer del 12VH.
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 13 di
30
2 - Software applicativo per Ciabatta
In questo capitolo si fornisce la descrizione della filosofia di funzionamento del software applicativo realizzato
per il microprocessore EM783 utilizzato per il monitoraggio dei consumi delle utenze collegate alla ciabatta
intelligente.
La ciabatta intelligente è un dispositivo in grado di controllare i consumi di tre diverse utenze e di comunicarli
tramite Powerline modem all’unità principale composta dal terminale INDOLE. Le tre utenze possono essere
abilitate o disabilitate da comando remoto o secondo una logica locale, grazie alla presenza di tre relay
bistabili.
FIGURA 14 - SCHEMA LOGICO CIABATTA
Il controllo dei relay, la gestione del Powerline modem e il monitoraggio dei consumi viene realizzato dal
microprocessore EM783-MC3 prodotto da NXP. Parte della componentistica elettronica della ciabatta è
isolata e protetta da fusibile, varistore ed ESD, mentre il monitoraggio dei consumi e la tensione di
alimentazione della CPU EM783 è di tipo non isolato, per cui per poter programmare la ciabatta è necessario
utilizzare un’interfaccia isolante realizzata tramite opto-isolatori.
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 14 di
30
2.1 Metrology Engine
Il Metrology Engine rappresenta l‘interfaccia analogica del microprocessore EM783 in grado di eseguire
misurazioni di tensione e di corrente periodiche a partire dagli ingressi analogici di I_HIGHGAIN, VOLTAGE e,
opzionalmente, I_LOWGAIN.
VOLTAGE: il metrology esegue la misura AC della tensione di rete su questo ingresso analogico.
Essendo un pin a bassa tensione del microprocessore, non è possibile collegarci direttamente la
tensione di rete (220V), ma è necessario un front-end analogico esterno che mantiene immutata la
caratteristica sinusoidale del segnale di rete, ma ne scala l’ampiezza massima. Quest’ultima infatti
non deve superare la tensione di alimentazione del micro VDD=3.3V.
I_HIGHGAIN: il metrology esegue la misura AC del consumo di corrente di un’utenza su questo
ingresso analogico. Il segnale che arriva a questo pin viene generato da una resistenza di shunt
collegata in serie alla tensione di alimentazione dell’utenza. Come per il pin di VOLTAGE, anche
I_HIGHGAIN necessita di un front-end analogico esterno che mantiene immutata la caratteristica
sinusoidale del segnale di assorbimento, ma ne amplifica l’ampiezza in base alla massima misura di
corrente che si intende collegare all’utenza. Tipicamente questo pin viene utilizzato per misurare i
bassi assorbimenti, per cui l’amplificazione da impostare sul front-end deve essere alta, ma
comunque di un valore tale da mantenere il segnale I_ HIGHGAIN inferiore alla tensione di
alimentazione del micro VDD=3.3V. Per gli alti consumi, la misurazione effettuata con I_HIGHGAIN
non è veritiera in quanto l’alto guadagno fa saturare l’amplificatore e quindi il metrology non è in
grado di discriminare le diverse correnti assorbite.
I_LOWGAIN(opzionale): il metrology esegue la misura AC del consumo di corrente di un’utenza su
questo ingresso analogico. Il segnale che arriva a questo pin viene generato da una resistenza di
shunt collegata in serie alla tensione di alimentazione dell’utenza. Come per il pin di VOLTAGE, anche
I_LOWGAIN necessita di un front-end analogico esterno che mantiene immutata la caratteristica
sinusoidale del segnale di assorbimento, ma ne amplifica l’ampiezza in base alla massima misura di
corrente che si intende collegare all’utenza. Tipicamente questo pin viene utilizzato per misurare gli
alti assorbimenti, per cui l’amplificazione da impostare sul front-end deve essere bassa, ma
comunque di un valore tale da mantenere il segnale I_LOWGAIN inferiore alla tensione di
alimentazione del micro VDD=3.3V. Per i bassi consumi, la misurazione effettuata con I_LOWGAIN
non è veritiera in quanto il basso guadagno dell’amplificazione non permette al metrology di
discriminare le correnti assorbite utilizzando segnali ad ampiezza quasi nulla.
E’ possibile utilizzare contemporaneamente entrambi i segnali I_HIGHGAIN e I_LOWGAIN per misurare il
consumo della stessa utenza. Questo consente di avere misure maggiormente accurate su un range più
esteso di assorbimenti (in ampere) rispetto al singolo utilizzo di I_HIGHGAIN o di I_LOWGAIN. Il metrology
infatti validerà la lettura eseguita sul pin di I_HIGHGAIN per gli assorbimenti più bassi, mentre validerà quella
su I_LOWGAIN per i consumi più alti.
Il metrology, grazie ai segnali campionati da questi tre pin analogici, riesce ad eseguire una serie di calcoli tra
cui: potenza Attiva (W), potenza reattiva (Var), potenza apparente (VA), power-factor etc.. E’ inoltre possibile
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 15 di
30
compensare le misurazioni effettuate in base alle variazioni di temperatura e in base ai punti di calibrazione
programmabili via software.
Il micro EM783-MC3 prevede quindi 1 ingresso analogico di VOLTAGE valido per tutte e tre le utenza e 6
ingressi analogici che collegano i segnali HIGH_GAIN e LOW_GAIN di ciascuna utenza.
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 16 di
30
2.2 Diagramma stati logici
Il software implementato segue la struttura logica evidenziata nello schema a blocchi sottostante.
FIGURA 15 - DIAGRAMMA STATI LOGICI
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 17 di
30
2.3 Descrizione del firmware
La prima operazione che questo software implementa è quella di inizializzare le porte del micro EM783 e le
periferiche utilizzate.
In particolare, il blocco “CPU init” inizializza i clock utilizzati dal micro, abilita il SysTickTimer con il quale
vengono gestiti tutti i timer software necessari al monitoraggio dei consumi e configura tutti i pin di I/O
(ingresso/uscita) utilizzati dal micro.
Il blocco “POWERLINE init” inizializza la comunicazione seriale con la quale il micro EM783 scambia i dati con
la CPU ST7540 responsabile della trasmissione/ricezione dei dati sulla 220V. La comunicazione seriale è di
tipo sincrono per la scrittura e lettura dei registri del micro ST7540, mentre è di tipo asincrono per la
trasmissione e ricezione dei dati da inviare sulla 220V. L’interfaccia asincrona UART0 viene configurata con
le seguenti caratteristiche:
Baudrate
600/1200/2400/4800
Datasize
8
Parity mode
None
Flow control
None
Stop bits
1
TABELLA 1 - CARATTERISTICHE COMUNICAZIONE SERIALE
I pacchetti ricevuti sono considerati validi se rispettano il formato <STX><CMD><LEN><Data><CRC>
STX: 1 byte, carattere di inizio pacchetto (valore costante 0x02);
CMD: 1 byte, comando da eseguire;
LEN: 1 byte, lunghezza del campo <Data>;
<Data>: payload del pacchetto (dim max 255 byte);
CRC: 1 byte, contiene il valore 1 + somma su un byte dei campi STX, CMD, LEN e <Data>.
Il blocco “METROLOGY init” inizializza i pin VOLTAGE, I_HIGHGAIN e I_LOWGAIN (per le tre utenze) come
ingressi analogici e abilita la periferica ADC che campiona costantemente questi pin per ricostruire
l’andamento dei relativi segnali di tensione e corrente. In questa fase vengono infine settati i parametri di
calibrazione del metrology.
Il Blocco “TIMER load” inizializza un timer dedicato allo scadere del quale vengono letti i valori di
assorbimento restituiti dal metrology per le tre diverse utenza.
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 18 di
30
Terminata la fase di inizializzazione, il software entra nello stato “MAIN loop”. In questa fase il micro EM783
esegue una serie di controlli per stabilire se sono arrivati comandi validi dal PowerLine modem o se è scaduto
il timer per la lettura del metrology.
Timer misurazioni: Allo scadere del timer viene richiamata la funzione di metrology read che restituisce i
valori relativi all’assorbimento misurato di ciascuna utenza. In particolare la funzione restituisce:
V: valore quadratico medio della tensione di rete
F: frequenza di lavoro
T: temperatura di lavoro
I: valore quadratico medio della correte assorbita in A
P: potenza attiva in Watt
S: potenza apparente in VA
PF: power Factor 0.00-1.00
Q: nonactive Power in var
Ricezione pacchetto PowerLine modem: Se viene ricevuto un pacchetto dal powerline modem, il software
ne esegue il parser, identifica il tipo comando, lo esegue e trasmette la risposta al comando richiesto. Di
seguito vengono descritti nel dettaglio i messaggi scambiati tra PowerLine e EM783. Con Rx e Tx vengono
rappresentati rispettivamente i pacchetti ricevuti e i pacchetti di risposta trasmessi dal micro EM783.
Versione SW EM783 [CMD_INQUIRY= 0x00]: comando con cui viene richiesto al micro EM783 l’identificativo
della ciabatta, il codice software e la relativa versione.
RX
<STX><0x00><0x00><crc>
TX
<STX><0x00><len><ID ciabatta|code_sw|version><crc>
ID ciabatta = es: 0xAABBCCDDEEFF
code_sw = 82023100
version = V0.1
'|' = separatore di campo
Chiusura Relay [CMD_RELAY_SET= 0x01]: comando per chiusura del relay selezionato. In questo caso l’utenza
riceve la tensione di rete 220V.
RX
<0x02><0x01><0x01><mask><crc>
(mask & 0x01) = 1 chiude relay 1 (utenza accesa)
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 19 di
30
(mask & 0x02) = 1 chiude relay 2 (utenza accesa)
(mask & 0x04) = 1 chiude relay 3 (utenza accesa)
TX
<0x02><0x01><0x00><0x04>
Apertura Relay [CMD_RELAY_RESET= 0x02]: comando per apertura del relay selezionato. In questo caso
l’utenza non riceve la tensione di rete 220V.
RX
<STX><0x02><0x01><mask><crc>
(mask & 0x01) = 0 apre relay 1 (utenza spenta)
(mask & 0x02) = 0 apre relay 2 (utenza spenta)
(mask & 0x04) = 0 apre relay 3 (utenza spenta)
TX
<STX><0x02><0x00><0x05>
Lettura assorbimento [CMD_READ_CHANNEL= 0x03]: viene richiesto l’ultimo dato acquisito del metrology
dell’utenza selesionata.
RX
<STX><0x03><0x01><mask><crc>
(mask & 0x01) = 1 lettuta utenza 1
(mask & 0x02) = 1 lettuta utenza 2
(mask & 0x04) = 1 lettuta utenza 3
(mask & 0x08) = 1 lettuta utenza 1,2,3
TX
<STX><0x03><len><Data><crc>
Dove il campo Data rappresenta una combinazione dei seguenti valori:
ID ciabatta
Identificativo della ciabatta
Voltage
Tensione misurata in V*100 (220.36 -> 22036)
Frequency
Frequenza di lavoro in Hz*100 (50.23 -> 5023)
Temperature
Temperatura in °C*10 (26.9 -> 269)
K1_Status
Stato relay K1 aperto o chiuso
K1_I
Corrente consumata utenza K1 in mA
Progetto INDOLE
Innovative Domotics for Living and Entertainment
K1_P
Potenza attiva utenza K1 in Watt
K1_PF
Power factor utenza K1
K2_Status
Stato relay K2 aperto o chiuso
K2_I
Corrente consumata utenza K2 in mA
K2_P
Potenza attiva utenza K2 in Watt
K2_PF
Power factor utenza K2
K3_Status
Stato relay K3 aperto o chiuso
K3_I
Corrente consumata utenza K3 in mA
K3_P
Potenza attiva utenza K3 in Watt
K3_PF
Power factor utenza K3
Pagina 20 di
30
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 21 di
30
3- Software applicativo per scheda Sensori INDOLE
In questo capitolo si fornisce la descrizione della filosofia di funzionamento del software applicativo realizzato
per il microprocessore CC1110 utilizzato per la gestione dei sensori della scheda Engine di INDOLE.
Le specifiche del terminale INDOLE prevedono il controllo di una serie di sensori e un led di emergenza da
attivare in caso di mancanza di alimentazione di rete. Queste periferiche non vengono gestite direttamente
dal sistema operativo installato sulla CPU Sitara, ma dal microcontrollore della Texas Instruments CC1110
anch’esso presente sul terminale.
FIGURA 16 - SCHEMA LOGICO CC1110
Il CC1110 deve quindi:
Raccogliere le letture del sensore di temperatura ambientale LM60
Raccogliere le letture del sensore di prossimità e intensità luminosa VCNL4000
Trasferire le informazioni raccolte al Sitara tramite comunicazione seriale
Gestire la procedura di “Emergenza”. Questa procedura permette al CC1110 di poter accendere il
Led di emergenza (MXM8-PW50) in caso di mancanza di tensione di rete all’interno di un’abitazione,
tenendo conto della luminosità ambientale presente al momento del blackout. Il Led può essere
acceso grazie al circuito di power management che permette di alimentare il CC1110 da due diverse
sorgenti: dalla tensione 3.3V prodotta a partire dalla tensione di rete o dalla batteria ricaricabile a
3.7V prevista sul terminale.
Gestire la procedura di “Notifica Presenza”. Questa procedura permette al CC1110 di notificare al
sistema operativo la presenza di una persona nei pressi del terminale. La notifica viene eseguita per
mezzo del segnale digitale CCOUT1 che collega i due microprocessori.
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 22 di
30
3.1 Diagramma stati logici
Il software implementato segue la struttura logica evidenziata nello schema a blocchi sottostante.
FIGURA 17 - DIAGRAMMA STATI LOGICI
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 23 di
30
3.2 Descrizione del firmware
La prima operazione che questo software implementa è quella di inizializzare le porte del micro CC1110 e le
periferiche utilizzate.
In particolare, il blocco “CPU init” inizializza i clock utilizzati dal micro, abilitata il SysTickTimer con il quale
vengono gestiti tutti i timer software necessari alla gestione dei sensori e configura tutti i pin di I/O
(ingresso/uscita) utilizzati dal micro.
Il blocco “UART init” inizializza la comunicazione seriale con la quale il CC1110 scambia i dati con la CPU
Sitara. In questa fase viene configurata la porta UART1 con le seguenti caratteristiche:
Baudrate
9600
Datasize
8
Parity mode
none
Flow control
none
Stop bits
1
TABELLA 2 - CARATTERISTICHE COMUNICAZIONE SERIALE
I pacchetti ricevuti, mediante
<STX><CMD><LEN><Data><CRC>
interrupt,
sono
considerati
validi
se
rispettano
il
formato
STX: 1 byte, carattere di inizio pacchetto (valore costante 0x02);
CMD: 1 byte, comando da eseguire;
LEN: 1 byte, lunghezza del campo <Data>;
<Data>: payload del pacchetto (dim max 255 byte);
CRC: 1 byte, contiene il valore 1 + somma su un byte dei campi STX, CMD, LEN e <Data>.
Il blocco “SENSOR init” inizializza le periferiche necessarie per la gestione ed il controllo dei sensori di
temperatura e di prossimità e luce ambientale. In particolare per poter leggere il sensore di temperatura
LM60 viene configurata la porta ADC del micro, mentre per la lettura del sensore di prossimità e luce
ambientale VCNL4000 viene abilitata l’interfaccia i2c bus del micro.
Il Blocco “TIMER load” inizializza un timer dedicato (SensTout) allo scadere del quale vengono letti i sensori
di temperatura, prossimità e luce ambientale.
Terminata la fase di inizializzazione, il software entra nello stato “MAIN loop”. In questa fase il micro CC1110
esegue una serie di controlli per stabilire se sono arrivati comandi validi dal Sitara tramite protocollo seriale
o se è scaduto il timer per la lettura dei sensori.
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 24 di
30
Ricezione pacchetto seriale: Se viene ricevuto un pacchetto sulla seriale, il software ne esegue il parser,
identifica il tipo comando, lo esegue e trasmette al Sitara la risposta al comando richiesto. Di seguito vengono
descritti nel dettaglio i messaggi scambiati tra Sitara e CC1110. Con Rx e Tx vengono rappresentati
rispettivamente i pacchetti ricevuti e i pacchetti di risposta trasmessi dal micro CC1110.
Versione SW CC1110 [PROT_CMD_VER= 0x00]: comando con cui viene richiesto al CC1110 il codice software
e la relativa versione.
RX
<STX><0x00><0x00><crc>
TX
<STX><0x00><15><code_sw|version><crc>
code_sw = 82023500
version = V0.1
'|' = separatore di campo
Reset [PROT_CMD_RESET= 0x01]: comando per eseguire un reset software del micro CC1110.
RX
<STX><0x01><0x00><crc>
TX
<STX><0x01><0x00><crc>
Il micro resetta solo dopo aver terminato la trasmissione della risposta.
ON/OFF LED di emergenza [PROT_CMD_LED= 0x02]: commando per accensione o spegnimento del led di
emergenza.
RX
<STX><0x02><0x01><status><crc>
status: 1 ON, 0 OFF
TX
<STX><0x02><0x00><crc>
Lettura sensore di temperatura LM60 [PROT_CMD_READ_TEMP= 0x03]: viene richiesto l’ultimo dato
acquisito della temperatura ambientale. Il valore viene restituito su due byte e rappresenta il valore della
temperatura in °C*10 (esempio 257 equivale a 25.7 °C)
RX
<STX><0x03><0x00><crc>
Progetto INDOLE
Innovative Domotics for Living and Entertainment
TX
Pagina 25 di
30
<STX><0x03><0x02><TEMP_H><TEMP_L><crc>
TEMP_H: byte più significativo della temperatura con segno
TEMP_L: byte più significativo della temperatura
Lettura sensore prossimità e luce ambientale [PROT_CMD_READ_PROX= 0x04]: viene richiesto l’ultimo dato
acquisito dal sensore di prossimità e luce ambientale.
RX
<STX><0x04><0x00><crc>
TX
<STX><0x04><0x04><PROX_H><PROX_L><LIGHT_H><LIGHT_L><crc>
PROX_H: byte più significativo sensore prossimità
PROX_L: byte più significativo sensore prossimità
LIGHT_H: byte più significativo luminosità amb
LIGHT_L: byte più significativo luminosità amb
Attivazione emergenza [PROT_CMD_EMERGENCY= 0x05]: comando per attivazione della procedura di
emergenza in caso di mancanza di alimentazione. Attivandola il CC1110 stabilisce se accendere la luce di
emergenza in caso di mancanza di alimentazione in base alla soglia di luminosità ambientale impostata con
questo comando
RX
<STX><0x05><0x03><ENABLE><LIGHT_THRE_H><LIGHT_THRE_L><crc>
ENABLE: 1 abilita emergenza, 0 non abilita emergenza
LIGHT_THRES_H: byte più significativo della soglia luminosità amb
LIGHT_THRES_L: byte più significativo della soglia luminosità amb
TX
<STX><0x05><0x00><crc>
Attivazione notifica presenza [PROT_CMD_PRESENCE = 0x05]: comando per attivazione della procedura di
notifica al Sitara della presenza di persone vicino al terminale. Attivandola il CC1110 muove il segnale CCOUT1
che lo collega al Sitara in base alla soglia di prossimità impostata con questo comando. Livello del segnale
pari a 1 presenza, 0 no.
RX
<STX><0x06><0x01><ENABLE><PROX_THRE_H><PROX_THRE_L><crc>
ENABLE: 1 abilita notifica presenza, 0 non abilita notifica
PROX_THRE_H: byte più significativo della soglia prossimità
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 26 di
30
PROX_THRE_L: byte più significativo della soglia prossimità
TX
<STX><0x06><0x00><crc>
Timer sensori: Allo scadere del timer SensTout vengono letti i sensori di temperatura, prossimità e luce
ambientale. In questa fase inoltre vengono controllate le flag per la gestione delle procedure di “Emergenza”
e “Notifica Presenza“.
“Emergenza”: se questa procedura viene attivata, il software controlla se il micro è alimentato
tramite batteria e se il valore letto di intensità luminosa è inferiore ad un determinata soglia. Se
entrambe le condizioni sono vere il software accende il Led di emergenza e lo mantiene acceso fin
quando non viene ristabilita la tensione di rete o fin quando l’intensità luminosa ritorna sopra soglia.
Per evitare false accensioni/spegnimenti del led, la procedura di “Emergenza” viene eseguita
utilizzando un tempo di debounce di 400msec.
“Notifica Presenza”: se questa procedura viene attivata, il software controlla se il valore di prossimità
letto supera un determinata soglia. Se questa condizione è vera il CC1110 notifica al Sitara la presenza
di una persona vicina al terminale INDOLE andando a settare a livello logico alto il segnale CCOUT1
che collega i due microprocessori. Quando invece la persona si allontana dal terminale il segnale
viene riportato basso.
Per evitare false notifiche verso il Sitara, la procedura di “Notifica Presenza” viene eseguita
utilizzando un tempo di debounce di 400msec.
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 27 di
30
4 – Sistema operativo: Android 4.2.2 kernel Linux 3.2.0
Il sistema operativo adottato a supporto della piattaforma è un sistema Android Kitkat 4.4.2, derivato dal BSP
che Texas Instrument distribuisce a corredo dei sistemi Sitara, ovvero quello prelevato dal repository
denominato “rowboat”.
Il kernel associato è un Kernel Linux 3.2.0.
Nello specifico non sono state apportate modifiche nel codice alla parte di sistema (framework ed applicativi)
Android, e per quel che riguarda quella componente ci si è limitati ad una opportuna configurazione per
adattarsi alle peculiarità del prodotto. In particolare: presenza di scheda di rete wireless Wilink8, e processore
AM3357, ovvero senza GPU.
Poichè la piattaforma di riferimento era la beaglebone Black. l'istruzione di comando utilizzata è stata:
make TARGET_PRODUCT=beaglebone droid kernel_build wl12xx_compat -j4
Va segnalato che, come da indicazioni presenti sul wiki Texas Instrument, la app per gestire la galleria
immagini, ed altre app che utilizzano le accelerazione SGX, non funzioneranno correttamente su questa
piattaforma:
Applications which depends on OpenGLES 2.0 APIs (e.g. Gallery) would not work correctly without
SGX libraries
Live Wallpapers depends on OPENGLES2.0 APIs and will not load if SGX is not enabled. Change to
Static wallpaper after booting. Or disable Live wallpaper from device/ti/<product-name>/overlay
Per il resto si tratta di un sistema Android completo, con possibilità di debug via seriale, oppure tramite usb
o wifi, con lo strumento software adb contenuto nel sistema Android standard.
Per la compilazione di tale sistema sono state seguite le istruzioni riportate sul wiki di Texas Instrument della
Developer Guide:
http://processors.wiki.ti.com/index.php/TI-Android-JB-4.2.2-DevKit-4.1.1_DeveloperGuide
La compilazione di Android richiede uno dei seguenti ambienti software sul computer di compilazione:
- Ubuntu 10.04 – 64bit con i seguenti pacchetti:
git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev libc6-dev lib32ncurses5-dev ia32libs x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev libgl1-mesa-dev g++-multilib
mingw32 tofrodos python-markdown libxml2-utils xsltproc minicom tftpd uboot-mkimage expect
- Ubuntu 12.04 – 64bit con i seguenti pacchetti:
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 28 di
30
git-core gnupg flex bison gperf build-essential zip curl libc6-dev libncurses5-dev:i386 x11proto-coredev libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 libgl1-mesa-dev g++-multilib mingw32
openjdk-6-jdk tofrodos python-markdown libxml2-utils xsltproc zlib1g-dev:i386 minicom tftpd
uboot-mkimage expect libgl1-mesa-dri
L'SDK Java richiesto è il: jdk-6uXX-linux-x64.bin where XX is the JDK 6 update version.
Per quanto riguarda il kernel, sono state apportate solo leggeri aggiustamenti sulla piattaforma:
1 - è stato agganciato il display LCD 24 linee. Questo ha richiesto la riorganizzazione del muxing nel seguente
modo:
{"lcd_data0.lcd_data0",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data1.lcd_data1",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data2.lcd_data2",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data3.lcd_data3",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data4.lcd_data4",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data5.lcd_data5",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data6.lcd_data6",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data7.lcd_data7",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data8.lcd_data8",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data9.lcd_data9",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data10.lcd_data10",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data11.lcd_data11",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data12.lcd_data12",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data13.lcd_data13",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data14.lcd_data14",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"lcd_data15.lcd_data15",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA},
{"gpmc_ad8.lcd_data16",
OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT},
{"gpmc_ad9.lcd_data17",
OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT},
{"gpmc_ad10.lcd_data18",
OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT},
{"gpmc_ad11.lcd_data19",
OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT},
{"gpmc_ad12.lcd_data20",
OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT},
Progetto INDOLE
Innovative Domotics for Living and Entertainment
{"gpmc_ad13.lcd_data21",
OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT},
{"gpmc_ad14.lcd_data22",
OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT},
{"gpmc_ad15.lcd_data23",
OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT},
{"lcd_vsync.lcd_vsync",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT},
{"lcd_hsync.lcd_hsync",
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT},
{"lcd_pclk.lcd_pclk",
Pagina 29 di
30
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT},
{"lcd_ac_bias_en.lcd_ac_bias_en", OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT},
{"gpmc_clk.gpio2_1",
OMAP_MUX_MODE7 | AM33XX_PIN_OUTPUT},
2 - è stato previsto lo sviluppo del driver per la comunicazione verso il microcontrollore.
Il kernel a cui ci si è appoggiati è quello rilasciato da Texas assieme al suo bsp per la piattaforma SItara: Linux
kernel versione 3.2.0.
Per la compilazione di tale kernel è stato usato il crosscompilatore disponibile all'interno dell'ambiente
Android SDK: arm-eabi-4.6-gcc e gli altri strumenti del tool.
La configurazione prescelta per generare il menuconfig è stata quella denominata:
am335x_evm_android_defconfig, per cui la sequenza di comandi da adottare per preparare l'immagina
binaria del kernel è stata:
$ cd <android source path>/kernel
$ make ARCH=arm CROSS_COMPILE=arm-eabi- distclean
$ make ARCH=arm CROSS_COMPILE=arm-eabi- am335x_evm_android_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-eabi- uImage
L'immagine ottenuta andrà poi copiata nella partizione di boot della scheda uSD da preparare, assieme al
bootloader (che non è stato alterato dal nostro sviluppo).
Le operazioni da compiere sono pertanto:
$ mkdir image_folder
$ cp uEnv.txt image_folder
$ cp kernel/arch/arm/boot/uImage image_folder
$ cp u-boot/u-boot.img image_folder
$ cp u-boot/MLO image_folder
Progetto INDOLE
Innovative Domotics for Living and Entertainment
Pagina 30 di
30
$ cp out/target/product/<product-name>/rootfs.tar.bz2 image_folder
$ cp Media_Clips image_folder
$
cp
<android-sources>/external/ti_android_utilities/am335x/mk-mmc/mkmmc-android.sh
image_folder
$ cd image_folder
$ sudo ./mkmmc-android.sh /dev/sd<sd card mount-point> MLO u-boot.img uImage uEnv.txt
rootfs.tar.bz2 Media_Clips
Da quel momento in poi la scheda uSD è pronta per essere inserita nella scheda ed avviata.
