4. La nuova realizzazione: Hardware
n questo capitolo verrà data una breve descrizione delle risorse hardware messe a disposizione dal DSP, dalla scheda e dall’ambiente di sviluppo scelti per la realizzazione del prototipo del nostro sistema. Saranno inoltre descritti il chipset Bluetooth utilizzato e le componenti hardware messe a disposizione dalla scheda aggiuntiva che è stata realizzata, necessaria al funzionamento ed alla espandibilità del sistema.
I
4.1 L’hardware Bluetooth
L’hardware Bluetooth consta di due entità distinte: gli auricolari all’interno dei caschi ed il chipset presente nella centralina sulla moto.
Come detto, è stata fatta la scelta strategica di utilizzare nei caschi degli auricolari headsets standard per telefono cellulare: questo consente la massima libertà, da parte dell'utente, di scegliere quale dispositivo utilizzare, senza la necessità di acquistare componentistica ad hoc. Inoltre si sfrutta tutto il lavoro di sviluppo parallelo, relativo agli auricolari headsets (peso, dimensioni, ergonomicità, consumo di potenza) e la diffusione sempre maggiore di questi dispositivi sul mercato, che ne causerà il crollo dei costi.
Nello sviluppo del prototipo sono stati utilizzati due headsets Sony Ericsson HBH-20, la cui foto è visibile in fig 4.1.
Figura 4.1: Auricolare Bluetooth Sony Ericsson HBH-20
Il chipset utilizzato dal gateway è invece il BlueCore 02 di CSR (Cambridge Silicon Radio), un dispositivo single chip integrato con tecnologia CMOS a 0.18 µm. Per il testing dell’applicazione questo dispositivo è stato utilizzato montato su una scheda di sviluppo Casira, prodotta dalla stessa CSR.
Uno schema a blocchi del BlueCore 02 è visibile in figura 4.2: si possono distinguere le tre parti principali del chip, che gestiscono rispettivamente l’interfaccia aerea, il controllo del chip e le interfacce.
L’architettura del chipset comprende i seguenti elementi:
• Un microcontrollore XAP2 dotato di interrupt-controller ed event-timer, che esegue la parte di software Bluetooth che in fase di partizionamento dell’applicazione si è deciso che dovesse girare sull’host controller, e controlla le interfacce radio e host. E’ stato scelto un microprocessore RISC a 16 bit, per avere basso consumo di potenza ed un efficiente uso della memoria. Lavora a 16 MHz, e la sua potenza di calcolo è di 8 MIPS, di cui però 6 servono alla gestione dello stack di protocollo; ne
restano quindi solo due per l’applicazione, ma sono più che sufficienti dato lo scarso carico di lavoro che questo microcontrollore dovrà smaltire.
• Una Memory Management Unit (MMU) che fornisce un numero di buffer circolari allocati dinamicamente, che immagazzinano i dati in transito sull’interfaccia aerea. L’allocazione dinamica della memoria assicura un uso efficiente della RAM, ed è eseguita da una MMU hardware per minimizzare i sovraccarichi del processore durante i trasferimenti voce/dati.
• Un Burst Mode Controller (BMC), che durante la trasmissione radio costruisce un pacchetto con le informazioni sull’intestazione precedentemente caricate su registri mappati in memoria, e con i dati da trasmettere presi dal relativo registro circolare sulla RAM. Durante la ricezione radio, il BMC immagazzina l’intestazione del pacchetto in registri memory-mapped, ed i dati nel relativo registro circolare sulla RAM. Quest’architettura minimizza l’intervento del processore durante trasmissione e la ricezione.
• Un Physical Layer Hardware Engine: è un DSP dedicato che effettua alcune delle operazioni più comuni sui pacchetti di dati inviati e ricevuti attraverso l’interfaccia aerea. Invece le conversioni dei dati audio in A- law e µ-law vengono eseguite dal microcontrollore.
• RAM: Vi sono 32 Kbytes di RAM on-chip, suddivisa tra registri circolari (usati per immagazzinare voce o dati per ogni connessione attiva) e memoria general purpose richiesta per la gestione dello stack Bluetooth.
• Una External Memory Driver (XMD): è un’interfaccia driver per memoria esterna, che può essere usata per connettere sia memoria Flash che memoria RAM.
• Interfacce: sono presenti, integrate sul chip, le seguenti risorse di comunicazione:
o un set di interfacce seriali per la comunicazione con un sistema host (UART, USB e SPI), tutte in grado di supportare trasferimenti audio con elevati baud-rate;
o Un’interfaccia Audio PCM, per la trasmissione e la ricezione continua di dati audio con codifica PCM.
o Un un totale di 15 terminali (12digitali e 3 analogici) di I/O programmabili (Programmable Input Output, PIO), controllati da un firmware che gira sul dispositivo.
Dalla descrizione delle risorse integrate nel chipset BlueCore risulta evidente che la potenza di calcolo disponibile non è assolutamente sufficiente per i requisiti del sistema. Inoltre anche i due MIPS dichiarati sono in realtà fittizi, dato che, per ragioni di protezione del firmware che gira sul microprocessore integrato sul chipset (e per ragioni inerenti il copyright sul firmware stesso) l’esecuzione di una porzione di codice utente è demandata ad un meccanismo di macchina virtuale, cioè un ambiente sicuro ed isolato per eseguire il codice utente.
La macchina virtuale ha accesso solo ad alcune risorse, ed è comunque subordinata in priorità al firmware che gestisce lo stack di protocollo; questo significa che prima di eseguire ogni istruzione del codice utente,il processore salva in memoria lo stato del programma principale, recupera dalla memoria lo stato della macchina virtuale, verifica che l’istruzione da eseguire non vada a causare un errore ed infine, se il controllo è andato a buon fine, esegue l’istruzione. Fatto questo ripristina lo stato della macchina ricaricando il programma principale.
Figura 4.2 Schema a blocchi del BlueCore 02
In tal modo ogni istruzione del codice utente viene a “costare” fino a 100 operazioni del microcontrollore, e la potenza di calcolo effettiva si riduce a circa 20 KIPS, insufficienti per eseguire applicazioni complesse.
Questa carenza rende necessaria la presenza di un altro elaboratore, che verrà connesso al BlueCore tramite una porta seriale UART. Come detto, l’elaboratore host è stato scelto nel DSP Blackfin BF533 di Analog Devices;
passiamo ora alla descrizione di questa parte del sistema.
4.2 Il DSP Blackfin ed il suo ambiente di sviluppo
In questo paragrafo si darà una breve descrizione del “cervello pensante”
del sistema, il Digital Signal Processor (DSP). Saranno presentate sia le caratteristiche fisiche del processore stesso che quelle della scheda di sviluppo EZ-LITE, e sarà presentato brevemente l’ambiente di sviluppo software VisualDSP++.
4.2.1 Il Processore: core, architettura, memoria e periferiche.
Il DSP scelto per realizzare il sistema è il Blackfin ADSP BF533, prodotto dalla Analog Devices. Questo è un processore single chip specificatamente disegnato per le comunicazioni digitali e per le applicazioni multimediali: la sua massima frequenza di clock è infatti 756 MHz (594 MHz per la versione utilizzata).
Di seguito si dà una breve descrizione dell’architettura del processore[7].
• Il Core: Il core del Blackfin (vedi fig. 4.3) contiene due moltiplicatori a 16 bit, due accumulatori a 40 bit, due ALU a 40 bit, 4 ALU video a 8 bit ed uno shifter a 40 bit. Le unità di calcolo possono processare dati ad 8, 16
o 32 bit, provenienti dai registri del processore. Sono disponibili 8 registri a 32 bit, che, operando con dati a 16 bit, possono essere visti come 16 registri a 16 bit.
Figura 4.3: Core, Data Address Generator e Program Sequencer Control Unit del Blackfin BF533.
Ogni blocco MAC (moltiplicatore/accumulatore) può eseguire una moltiplicazione 16 bit per 16 bit in un ciclo di clock, rendendo disponibile il risultato nell'accumulatore a 40 bit. Sono supportati inoltre l'arrotondamento e la saturazione.
Le ALU eseguono un set tradizionale di operazioni logiche ed aritmetiche su dati a 16 e/o 32 bit. Inoltre sono incluse varie istruzioni speciali per accelerare vari compiti nell'analisi dei segnali: sono presenti, ad esempio, alcune primitive della divisione.
Per certe operazioni su 16 bit ogni ALU può lavorare in parallelo su due operazioni; facendo poi lavorare in parallelo le due ALU il core riesce ad eseguire 4 operazioni su 16 bit in un solo ciclo di clock.
Lo shifter, infine, esegue gli shift logici ed aritmetici.
Figura 4.4 Architettura del DSP Blackfin BF533
• L’architettura: l’architettura del processore (vedi figura 4.4) è la Micro Signal Architecture, sviluppata da Analog Devices ed Intel. Si tratta, in pratica, di un’architettura di tipo Harvard modificata, combinata con una struttura gerarchica della memoria, in cui si distingue tra una memoria di livello 1 (L1), che opera tipicamente alla stessa velocità del processore, senza alcuna latenza, e la memoria esterna, che è invece compatibile con lo standard PC133. Gli indirizzi sono generati da due Data Address Generator (DAG) pilotati dall’unità di controllo di flusso (Program Sequencer Control Unit) con l’ausilio di un blocco di 24 registri a 32 bit per le varie modalità di indirizzamento. I due DAG possono operare in parallelo, consentendo così due fetch simultanei in memoria.
• La memoria: il Blackfin vede la memoria come uno spazio unificato di 4G locazioni (indirizzi a 32 bit). Tutte le risorse, tra cui la memoria
interna, quella esterna ed i registri di controllo delle periferiche occupano sezioni separate di questo spazio comune di indirizzamento.
Le porzioni di memoria sono organizzate in una struttura gerarchica allo scopo di fornire un buon bilanciamento tra prestazioni e costo della memoria stessa nella maggior parte delle applicazioni.
La memoria interna (on chip) è la memoria di livello 1 (L1), che opera alla stessa velocità del core, e consiste in 80KB di SRAM per le istruzioni, 64KB di SRAM per i dati e 4KB di SRAM ad uso generico. Tra questi, 16 KB di memoria per le istruzioni e 32 KB di memoria per i dati possono essere configurati come cache.
La memoria esterna, a cui si accede tramite l'External Bus Interface Unit (EBIU), fornisce la possibilità di espandere la memoria del sistema con banchi di memorie SRAM, SDRAM e flash, fino ad un massimo di 132MB di memoria fisica.
• Le periferiche: Il processore Blackfin dispone di un notevole set di periferiche, connesse al core attraverso vari bus con elevata ampiezza di banda: in particolare sono presenti:
una UART (Universal Asinchronous Receiver Transmitter) con supporto per comunicazioni IrDA;
una porta SPI compatibile;
due porte seriali sincrone (SPORTs);
tre timers/contatori con supporto PWM;
un Real-Time clock;
un Watchdog timer;
una porta PPI (Parallel Peripheral Interface), in grado di supportare il formato video ITU-R 656 ed utilizzabile anche come set di piedini programmabili per l’ingresso/uscita (GPIO);
una porta JTAG per il debug delle applicazioni.
Per la nostra applicazione si sono rivelate essenziali la porta UART (connessione al BlueCore), le due SPORTs (SPORT0 per la connessione al codec e SPORT1 per emulare la seconda UART) e la SPI (per emulare la terza UART), nonché alcuni dei piedini GPIO ed il core timer.
Per agevolare il controllo di un così elevato numero di periferiche senza impegnare il processore per tutte le operazioni di I/O, è presente un controllore DMA a 12 canali, sia per gestire flussi di dati tra la memoria e le periferiche, sia per gestire flussi di dati tra varie parti della memoria.
E’ infine presente un controllore degli eventi che gestisce tutti gli eventi (si perdoni la ripetizione), sincroni ed asincroni, che possono modificare il flusso lineare del programma, vale a dire interruzioni, eccezioni, emulazione e reset. Questo controllore consente una completa programmabilità nel mascheramento e nella gestione della priorità delle sorgenti di interruzione stesse.
4.2.2 La scheda di sviluppo: l’architettura ed il codec integrato.
Come accennato, per lo sviluppo del prototipo il DSP è stato usato assieme alla scheda di sviluppo, la ADSP BF533 EZ-KIT Lite. Questa scheda è una evaluation board su cui sono montati il DSP e tutta una serie di componenti hardware che permettono la programmazione ed il debugging del processore, nonché un facile accesso alle sue periferiche. In particolare la scheda comprende[8]:
• Il DSP Blackfin BF533;
• 32 MB di memoria SDRAM, organizzata come 16M locazioni da 16 bit;
• 2 MB di memoria flash;
• Un codec audio AD1836, supportato da 4 ingressi e 6 uscite per jack RCA;
Figura 4.5: Architettura della ADSP BF533 EZ-KIT Lite
• Un encoder ed un decoder video (ADV7171 e ADV 7183);
• Un line driver UART/RS232 ADM3202 connesso ad un connettore DB9;
• Vari connettori per l’accesso alla piedinatura del DSP, la connessione di una interfaccia JTAG ed una porta USB per la programmazione ed il debugging del codice;
• 10 leds e 4 pulsanti;
• I regolatori serie ADP3338AKC-33, ADP3339AKC-33 e ADP3339AKC-5 per ottenere le tensioni di 3,3 V e 5 V.
4.2.2.1 Il codec audio AD1836
Un punto di forza del “pacchetto” è il codec audio[9]: l’AD1836 è un codec single chip ad alte prestazioni, che fornisce tre DAC e due ADC
stereo usando un’architettura Σ-∆ multibit. In figura 4.6 si può vedere uno schema funzionale del codec.
Figura 4.6: schema funzionale del codec AD1836
La comunicazione di campioni audio da/per il DSP avviene tramite una porta seriale sincrona SPORT, che può essere impostata per utilizzare svariati protocolli di comunicazione, come I2S, Left Justified, Right Justified, DSP mode, ADC e DAC packet mode 128 e 256.
Figura 4.7: comunicazione I2S
Le impostazioni di conversione, il protocollo di comunicazione dei dati, il guadagno ed il livello di picco degli ADC sono parametri programmabili attraverso una porta SPI in 15 registri a 16 bit interni al codec. Per il nostro progetto abbiamo scelto per i campioni audio una comunicazione I2S, che può essere schematizzata come in figura 4.7.
Come si vede ci sono due segnali di sincronizzazione, uno che segnala a quale canale (destro o sinistro) appartengono i campioni, l’altro che regola variazioni e campionamenti dei singoli bit. Le parole, da 16 a 24 bit, vengono trasmesse MSB first.
4.2.3 Adeguatezza delle risorse hardware
Le risorse hardware messe a disposizione dal complesso processore – scheda di sviluppo rispondono a quasi tutti i requisiti del sistema: in particolare si possono evidenziare i seguenti punti:
• La potenza di calcolo è più che sufficiente, anche considerando le risorse che potrebbero essere impiegate dagli algoritmi di soppressione del rumore e di riconoscimento e sintesi vocale;
• La memoria a disposizione è addirittura sovrabbondante, essendo dimensionata per supportare applicazioni video;
• Il collegamento con il chipset Bluetooth è garantito dalla porta UART, controllata in ingresso ed in uscita da due canali del DMA;
• Il codec audio fornisce un numero di ingressi (4) ed uscite (6) adeguate ai bisogni del sistema. Il protocollo con cui il codec comunica con il DSP è di semplice configurazione ed utilizzo, e la porta seriale sincrona su cui viaggiano i campioni audio è asservita, sia in ingresso che in uscita, al controllore DMA, impiegandone due canali.
• Le altre interfacce garantiscono risorse di connettività aggiuntive che coprono un vasto spettro di sistemi interfacciabili.
Da altri punti di vista invece le risorse presenti sulla scheda non sono sufficienti:
• La scheda monta un regolatore di tensione che deve ricevere in ingresso una tensione continua a 7,5 V. A bordo di una moto la batteria eroga invece una tensione di 12-15V, e sono di solito presenti picchi di corrente spuri dovuti a picchi di potenza erogata/assorbita dalla batteria all’impianto elettrico del motoveicolo; si rende necessario quindi un sistema di alimentazione che effettui la traslazione in tensione dell’alimentazione, e che protegga la scheda dai picchi di corrente.
• La decisione di interfacciare il sistema con l’esterno tramite una porta seriale RS-232 richiederebbe la disponibilità di un’altra UART: poiché questa non è disponibile, si rende necessario non solo emularla via software tramite una porta seriale sincrona, ma si dovrà anche introdurre dell’hardware aggiuntivo per ottenere i livelli di tensione standard RS-232 (±12 V).
• La creazione di una seconda rete Bluetooth per il telefono GSM richiede la disponibilità di una terza UART: anch’essa dovrà essere emulata da un’altra porta seriale sincrona, e richiederà dell’hardware aggiuntivo;
• I chipset Bluetooth, sia quello relativo alla piconet primaria che quello relativo alla piconet del GSM non possono chiaramente venire integrati sulla scheda di sviluppo del DSP. Inoltre questi chip necessitano di alimentazione a 3,15 V, quindi si dovrà provvedere alla loro alimentazione con della circuiteria ad hoc.
Per la descrizione dell’hardware inserito sulla scheda aggiuntiva si veda il paragrafo 4.3.
4.2.4 L’ambiente di sviluppo VisualDSP++.
Allo scopo di comprendere come sia stato possibile procedere alla scrittura del codice ed al suo debugging, è opportuno introdurre alcune delle caratteristiche dell’ambiente di sviluppo che Analog Devices fornisce insieme alla EZ-KIT Lite.
Questo ambiente di sviluppo permette di programmare il DSP nei linguaggi C, C++ e assembler, eventualmente scrivendo programmi multilinguaggio. E’ inoltre disponibile un nucleo di sistema operativo (Visual DSP kernel) per agevolare o sviluppo di applicazioni multi-thread.
Il vero punto di forza dell’ambiente di sviluppo è però dato dalla possibilità di seguire passo dopo passo l’esecuzione del codice, mantenendo sotto controllo la memoria, i registri interni al core del processore e quelli di gestione delle periferiche. Questo è possibile grazie alla porta USB presente sulla EZ-KIT Lite: tale porta viene usata per accedere alla memoria di programma del processore, e per eseguire i programmi stessi in modalità di emulazione. In questa modalità il processore viene controllato dall’applicazione che gira su PC, e la porta USB viene usata dal processore per inviare al PC il contenuto della memoria e dei registri generali e di configurazione.
4.3 Altro hardware
Come accennato nell’introduzione a questo capitolo, è stata realizzata una scheda aggiuntiva, che va a connettersi sotto la scheda di sviluppo del DSP. Questa scheda, il cui schema elettrico è visibile in figura 4.8, ospita a bordo i componenti a cui si è accennato nel paragrafo 4.2.3.
Procediamo ora alla descrizione dei singoli blocchi funzionali:
• Il connettore Batteria del motoveicolo, che riceve i cavi di alimentazione provenienti, appunto, dalla moto;
Figura 4.8: Schema elettrico della scheda aggiuntiva
• Il blocco 7.5 V Power Supply è un alimentatore switching basato sull'integrato LM2676T-ADJ prodotto dalla National semiconductor, che converte la tensione dai 14V forniti dalla batteria ai 7,5 V che necessitano in ingresso alla scheda EZ-KIT Lite;
• Il blocco 3.15 V Power Supply, che fornisce l’alimentazione a 3,15 V ai moduli Bluetooth, convertendo la tensione di ingresso a 7,5 V con quattro regolatori serie MAXIM Integrated Circiuts MAX604;
• Il blocco 3.3 V Power Supply, realizzato anch’esso con un MAX604, converte la tensione di ingresso a 7,5 V in tensione a 3,3 V per l'alimentazione dell'altra circuiteria presente sulla scheda aggiuntiva;
• I due blocchi RF Module 1 e 2 sono i due trasceiver Bluetooth: il primo (helmets) è il master della piconet a tre nodi che contiene i caschi, il secondo (mobile) è il transceiver su cui è caricato il profilo headset che si connette (come slave) al GSM creando la seconda piconet, se viene usata la connettività Bluetooth del telefono;
• Il blocco Reset and Ring Detection provvede a segnalare al DSP l’arrivo di una chiamata sul telefono GSM, e si occupa, su comando dell’utente (pressione di un pusante) di resettare i due chipset Bluetooth;
• Il blocco RS232 DSP è un line driver, basato sull’integrato ICL3223 della Intersil, che converte i livelli elettrici della porta UART del chipset Bluetooth relativo alla piconet a tre nodi nei livelli elettrici standard RS232. Questo blocco è poi connesso ad un connettore DB-9 standard.
E’ opportuno spiegare che è stato necessario ricorrere all’integrazione sulla scheda di questi componenti a causa di un bug hardware della scheda di sviluppo EZ-KIT Lite; infatti la soluzione più sensata sarebbe stata quella di prelevare i segnali direttamente con i livelli UART dal connettore EZlite CONNECTIONS (vedi sotto), ma si è incorsi in un conflitto elettrico dato dal fatto che il line driver presente sulla scheda di sviluppo non è disattivabile, ed è sempre connesso ai piedini del DSP:
per i segnali in uscita dal DSP non si hanno problemi, ma per quelli in ingresso si incorre in un conflitto, dato che il line driver impone, se ha ingresso logicamente nullo, la tensione alta (3,3 V) mentre la tensione di
ingresso dovrebbe essere quella imposta dal BlueCore. Sperimentalmente si è dimostrato che i livelli di tensione risultanti dal conflitto erano comunque nel range di riconoscibilità, ma si è preferito evitare del tutto una situazione comunque “stressante” per l’hardware uscendo dalla scheda di sviluppo tramite il connettore DB-9 (livelli RS232) e cablare i segnali all’altro connettore sulla scheda aggiuntiva, per poi ritraslare i livelli elettrici.
• Il blocco EZlite CONNECTIONS rappresenta il connettore a 90 piedini che connette la scheda aggiuntiva alla scheda di sviluppo su cui è montato il DSP. Da esso vengono prelevati:
o i piedini di comunicazione della porta SPI (SCK, MOSI, MISO) più due programmable flag, uno che ha la funzione di chip select per il dispositivo slave (vedi sotto) ed uno che, opportunamente settato, serve come flag di interruzione in ricezione;
o i piedini di trasmissione e ricezione della SPORT1, usata per l’emulazione software della seconda porta UART;
o un programmable flag che serve da sorgente di interruzione per la funzione di arrivo di chiamata.
• I due blocchi RS232 e SPI module sono utilizzati per l’emulazione delle porte UART tramite, rispettivamente, la porta SPORT1 e la porta SPI:
l'emulazione della UART con la SPORT avviene via software, ed il blocco RS232 effetua solo la traslazione di livello delle tensioni per riportarsi ai livelli RS232. Tale traslazione viene effettuata da un integrato ICL3223 della Intersil. Il blocco SPI module effettua invece sia l’emulazione della porta UART (via hardware) che la traslazione dei livelli, grazie ad un integrato MAXIM Integrated Circuits MAX3111.
Questi due moduli insistono sullo stesso connettore DB-9 poiché quest’ultimo è quello che viene usato per la connessione con l’interfaccia.
In pratica si è seguita questa filosofia: per il prototipo iniziale, in cui il telefono GSM è cablato, l’interfaccia è connessa sulla UART emulata da SPORT, e la porta SPI resta inutilizzata; per il prototipo successivo, in cui è prevista la connettività Bluetooth del GSM, l’interfaccia si sposta sulla UART emulata da SPI, mentre il BlueCore che supporta la seconda piconet si connette alla UART emulata da SPORT, lasciando inutilizzato il modulo RS232. Questa soluzione è stata adottata perché la UART emulata via SPI non è in grado di lavorare in DMA, e questo porrebbe dei seri problemi di gestione del traffico di dati se su quella linea dovessero transitare dei campioni audio.
