Capitolo 3

Capitolo 3

3 Hardware ed architettura del sistema.

3.1 Introduzione

In questo capitolo faremo una descrizione dettagliata dello hardware utilizzato per lo sviluppo dell’applicazione, in seguito verranno analizzate alcune possibili architetture delle scatternet al fine di arrivare ad una scelta definitiva, compatibile con i requisiti del progetto. Verranno, infine, discussi alcuni metodi di partizionamento dello stack di protocollo Bluetooth, cercando di evidenziare le peculiarità per ciascuno di essi.

3.2 Il chip Bluecore.

Per realizzare il sistema di comunicazione wireless proposto è necessario disporre di un core Bluetooth che costituisca la piattaforma hardware sulla quale sviluppare l’applicazione. Nel nostro caso la scelta è caduta su un dispositivo a singolo chip prodotto dalla C.S.R. (Cambridge Silicon Radio), commercializzato col nome di Bluecore02. Dunque, il sistema di sviluppo adoperato per il progetto consiste essenzialmente in tre moduli radio chiamati Casira, nei quali è

alloggiato il Bluecore02. Esso permette al progettista di familiarizzare con la tecnologia e gli offre la possibilità di arrivare ad un primo prototipo in tempi relativamente brevi, perché lo esonera, almeno nella prima fase di progetto, dalla necessità di realizzare hardware dedicato. Infatti, i moduli Casira sono equipaggiati con hardware sufficiente ad implementare un congruo numero di funzioni utili in fase di prototipazione e testing.

Prima di passare alla descrizione del sistema di sviluppo è opportuno soffermarsi a prendere un po’ di confidenza col dispositivo BlueCore02™. Esso è un sistema integrato su singolo chip in tecnologia CMOS 0.18 µm, ed il suo diagramma a blocchi funzionali è riportato in Figura 3-1. Si distinguono tre moduli principali: una sezione RF con il trasceiver ed il sintetizzatore di frequenza responsabili della trasmissione e ricezione sul canale fisico, una parte chiamata baseband and logic, dedicata alla gestione delle interfacce, della memoria e alle operazioni di banda base, ed, infine, un microcontrollore RISC, indispensabile per l’esecuzione dello stack di protocollo e di un’eventuale applicazione utente. Il microprocessore a bordo del BlueCore è uno XAP2, proprietario di CSR, un RISC capace di una potenza di calcolo di 8 MIPS di cui, però, solo una piccola parte è disponibile per l’utente. Questo processore sovrintende a tutte le operazioni necessarie ad eseguire lo stack di protocollo Bluetooth, impiegando 6 degli 8 MIPS disponibili, mentre i 2 MIPS residui sono, in parte, a disposizione dell’utente.

Questa limitazione condiziona pesantemente la possibilità di eseguire codici complessi direttamente a bordo del micro e costringe spesso ad affiancare al Bluecore un processore esterno. In questo caso siamo di fronte quindi ad un sistema a due processori in cui il micro esterno si dice host ed il core Bluetooth si dice host controller.

Il chip presenta un congruo numero di interfacce: USB, seriale sincrona SPI, UART, PCM ed infine una PIO (programmable I/O). È inoltre presente un driver di memoria per l’interfacciamento con la indispensabile memoria esterna, tipicamente una flash, sulla quale risiede lo stack di protocollo Bluetooth ed una eventuale applicazione utente.

Il chip Bluecore da solo non può funzionare, ma ha bisogno di alcuni (pochi per la verità), componenti esterni: la memoria flash, un quarzo, un transistor di passo per il regolatore di tensione interno al chip, alcuni condensatori e, naturalmente, un’antenna, componenti che nel nostro caso troviamo montati insieme al chip su di una piccola PCB (20x35mm circa).

3.3 Il modem Casira

.

Il Casira, mostrato in figura consiste in una quantità di componenti elettronici montati su una classica PCB di forma approssimativamente semicircolare di raggio 4 cm. Il componente essenziale montato su questa PCB è la piccola schedina [A] già descritta nel precedente paragrafo. Questa schedina non è saldata sul circuito stampato ma è fissata su un particolare alloggiamento con chiusura a scatto che permette all’utente di sostituirla con un’altra a suo piacimento, garantendo una elevata flessibilità e semplificando nettamente eventuali upgrades verso chip Bluetooth più evoluti. I contatti esterni di questa schedina rendono accessibili tutti i terminali del Bluecore, fatta eccezione per i pin relativi alla memoria e quelli a radiofrequenza, per il semplice fatto che essendo già opportunamente impegnati non avrebbe molto senso accedervi dall’esterno in un utilizzo normale. Tutto il resto dell’elettronica montata sulla scheda assolve a funzioni per così dire ausiliarie. È presente infatti un circuito di alimentazione con dei regolatori di tensione, un transceiver per l’adeguamento dei livelli elettrici della UART, un codec ed un amplificatore audio per le cuffie e il microfono, alcuni led, buffer per il pilotaggio delle linee e, naturalmente, tutti i connettori esterni.

Figura 3-2 : il Casira A

Questi componenti ausiliari danno la possibilità di interfacciarsi in maniera semplice col chip BlueCore02 montato sulla schedina. In questo modo sono possibili importanti funzioni come il back up e l’aggiornamento del firmware, e la modifica delle impostazioni del chip. Più in dettaglio, back up e aggiornamento del firmware sono facilmente effettuabili sfruttando un software di utilità fornito col chip, chiamato BlueFlash, che gira in ambiente Windows. Le impostazioni del chip sono memorizzate in un’area della flash riservata per questo scopo, detta Persistent Store, sulla quale è possibile intervenire mediante un altro software chiamato PSTool. Scrivendo opportuni valori nelle locazioni del Persistent Store è possibile controllare, ad esempio, le proprietà delle trame della UART, scegliere l’interfaccia per un eventuale host, impostare la modalita di funzionamento dei moduli, ossia il ruolo di ciascuno nella rete (master, slave o entrambi) ecc. Anticipiamo che i software BlueFlash e PSTool saranno utilizzati preliminarmente per adattare i chip al supporto della scatternet. Inoltre, sono disponibili altri programmi di utilità, detti Command Window e Watch Window, che vengono usati per mandare comandi ai moduli e per visualizzare gli eventi, ossia le risposte a tali comandi.

3.4 Partizionamento dello stack

Descritte alcune tipologie di scatternet nel capitolo 1, ed il modulo Bluetooth che verrà usato all’interno di ciascun nodo, è necessario decidere come quest’ultimi verranno realizzati, in particolare se dotarli o meno di intelligenza aggiuntiva rispetto al processore integrato nel chip Bluecore e, a seconda di questa scelta, come partizionare lo stack. Generalmente infatti, possiamo suddividere i dispositivi che sfruttano il Bluecore come core Bluetooth, ma il discorso vale naturalmente anche con chip diversi, in sistemi con o senza host. Nei primi, una parte più o meno consistente delle elaborazioni viene affidata ad un host esterno (un microcontrollore o un DSP), nei secondi, invece, tutte le elaborazioni

necessarie vengono effettuate da un software eseguito dal microcontrollore integrato nel Bluecore, che, nel caso di architetture in cui è presente un host, viene detto host controller. Nel caso di un sistema host-host controller è possibile, anzi necessario, decidere quali layer dello stack di protocollo far girare sul chip/host controller e quali sul micro esterno/host. Vediamo qual è la flessibilità che ci viene offerta in questo senso.

In Figura 3-3 sono illustrati tre modelli di partizionamento dello stack. Si osservi che lo stack qui rappresentato ha un elemento in più rispetto al solito, ed è il

device manager, un componente addizionale presente solo nella versione dello

stack fornita dalla CSR, ma ciò non cambia affatto la sostanza né inficia l’interoperabilità, perché esso è solo una entità mediatrice fra lo stack ed una eventuale applicazione utente, e permette di avere un interfaccia più uniforme. La prima possibilità di partizionamento è rappresentata dal cosiddetto split HCI, in figura 3-3.a in cui i layer dalla bandabase fino ad HCI girano sul chip, mentre tutti gli altri girano sul processore host insieme alla applicazione. Tipicamente questa è l’opzione che si sceglie quando l’host è piuttosto potente, come ad esempio un PC.

3-3.a 3-3.b 3-3.c

Figura 3-3 : modelli di partizionamento dello stack

Da notare che il layer HCI in figura 3-3.a non è sdoppiato, ma il disegno vuole solo esprimere la presenza su entrambi i “lati” di un driver per il protocollo di trasporto scelto fra USB, UART, RS232 e, nel caso del Bluecore, il BCSP, un protocollo seriale proprietario di CSR. La seconda (2-3.b) è una scelta intermedia fra lo split HCI e la soluzione full embedded; in questo caso tutto lo stack gira sul chip mentre l’applicazione e la sua interfaccia con lo stack alloggiano su un processore separato. Tipicamente ciò accade in quei sistemi che si vogliono dotare di un punto d’accesso Bluetooth ma non dispongono di risorse sufficienti per far girare lo stack, come ad esempio nei telefoni cellulari. Il terzo caso (2-3.c), infine, è quello cui si è accennato più sopra, ovvero quello di un sistema single chip che accoglie tutto il software. Ricordandoci delle limitazioni imposte alla potenza di calcolo disponibile per l’utente, sceglieremo questa soluzione solo nel caso di applicazioni non eccessivamente complesse.

3.5

Topologia della scatternet a tre nodi e loro requisiti.

Come descritto nel primo capitolo, le reti scatternet costituite da due piconet sono essenzialmente di tre tipi: nelle scatternet del primo tipo il nodo master di una piconet può partecipare come slave nell’altra piconet, mentre in quelle del secondo è uno dei nodi slave a partecipare attivamente (come slave) ad entrambe le piconet. Il terzo invece prevede la connessione tra due slave appartenenti a diverse piconet e la creazione di una terza piconet (C) tra di essi ( in figura 3-4, 3-5, 3-6).

L’architettura da noi scelta contiene tre nodi (A, B e C), due dei quali instaurano, inizialmente una piconet, dopodichè il terzo nodo si connette ad uno dei primi due, creando così la seconda piconet, quindi la scatternet. Si tratta, dunque, della scatternet più elementare, contenente soltanto due piconet, ma che diventa un modello base del caso in cui si connettono due motoveicoli, evento che capita più frequentemente. Supponiamo che il nodo A rappresenti la centralina di un motoveicolo ed il nodo B il casco del guidatore o del passeggero. Possiamo quindi immaginare che tra il nodo A e B esista una connessione master-slave attiva, vale a dire una piconet iniziale. Supponiamo, inoltre che un altro motoveicolo, la centralina del quale è rappresentata dal nodo C crei una connessione con uno dei nodi costituenti la piconet iniziale e instauri, così, una seconda piconet Le figure rappresentano, quindi, le tre possibili modalità con cui C può formare una scatternet con la piconet A-B.

Figura 3-4 : scatternet a tre nodi del primo tipo

Figura 3-6 : scatternet a tre nodi del terzo tipo

Nella scatternet rappresentata in Figura 3-4 il nodo A si connette come master al nodo B per formare la piconet 1, dopodiché accetta una richiesta di connessione come slave da parte del nodo C creando così la piconet 2. Il nodo A, quindi, deve partecipare attivamente in due diverse piconet, con due diverse sequenze di frequency hopping, e con ruoli diversi in ciascuna delle piconet. Ciò comporta una quantità di elaborazioni superiore rispetto al caso del funzionamento in una sola piconet.

Nella scatternet del secondo tipo (in Figura 3-5), i nodi A e B creano la piconet 1 come prima; la differenza sta nel fatto che ora il nodo C si connette come master al nodo B il quale si comporta da slave in entrambe le piconet. Quindi, in questo caso è il nodo B a necessitare di una capacità di calcolo superiore.

Anche nella terza tipologia, rappresentata in Figura 3-6, la piconet 1 è formata dai nodi A e B. Adesso il nodo B fa una richiesta di connessione, come master, al nodo C e quest’ultimo diventa lo slave. Per quanto riguarda la capacità di calcolo,

Master A

Piconet 1

_{Piconet 2}

Slave B_1

Master B_2

il discorso è identico al caso precedente, dato che è ancora il nodo B a dover supportare due connessioni in due piconet diverse.

Prima di fare una scelta sull’architettura del sistema è opportuno evidenziarne i requisiti.

Per quanto riguarda i nodi presenti sui caschi (il nodo B nel nostro caso), essi dovranno essere fisicamente poco ingombranti e leggeri per poterli comodamente alloggiare nello chassis di un casco senza influenzarne percettibilmente il peso, e consumare poca energia, per ottenere una lunga durata della batteria che li alimenterà. Sarà perciò opportuno costruirli con il numero più basso possibile di componenti. Una scelta naturale, allora, è quella di realizzarli cercando di sfruttare soltanto il chip Bluecore senza utilizzare un microcontrollore esterno, di conseguenza il potenziamento hardware e software per quanto riguarda il funzionamento in scatternet non deve riguardare gli slave. L’applicazione che dovrà girare su di essi, quindi, non sarà di complessità tale da richiedere l’utilizzo di un processore aggiuntivo, dovendo garantire il supporto alle procedure necessarie per connettersi da slave ad una piconet, cosa che può serenamente essere fatta con un sistema basato sul solo Bluecore02.

I nodi master (A e C, per intenderci), invece, non presentano, a patto di essere ragionevoli, particolari esigenze per quanto riguarda il consumo di energia, l’ingombro ed il peso, dovendo essere alloggiato a bordo della moto. Quindi è naturale che eventuali aggiunte di applicazioni dovranno riguardare questi nodi. La scelta ovvia è, dunque, quella dell’architettura della scatternet del primo tipo. Dal punto di vista dell’applicazione il master ha non solo il compito di controllare instaurazione mantenimento e disfacimento di una piconet e di gestire i vari segnali audio in maniera tale da implementare le varie funzioni richieste dal sistema, ma adesso si richiede che esso controlli creazione e mantenimento della scatternet. Per fare ciò la potenza di calcolo disponibile sul Bluecore non è sufficiente, e risulta quindi necessario utilizzare un processore aggiuntivo. Questa scelta però non è di per se sufficiente a definire l’architettura del sistema, perché è necessario decidere come partizionare lo stack.

3.6 Valutazione comparativa delle alternative architetturali

Scelta la topologia della scatternet dobbiamo decidere la maniera in cui realizzare ognuno dei tre nodi. Saranno passati ora in rassegna alcuni modelli architetturali del sistema, che in linea di principio, permettono di soddisfare le specifiche del nostro sistema, cercando di evidenziarne pregi e difetti per poi giungere ad una scelta.

In Figura 3-7 è rapresentata una prima architettura in cui tutti i nodi della scatternet sono realizzati con una struttura host-host controller. Le frecce bianche rappresentano il trasporto fisico utilizzato che può essere USB o UART, con protocollo H4, RS232 o BCSP. Una prima controindicazione all’utilizzo di questa struttura è che essa ci costringe ad usare un microcontrollore anche sui nodi destinati ad essere alloggiati sui caschi (in questo caso il nodo B), andando ad incrementare il numero di componenti e quindi ingombri e consumi, parametri assolutamente critici nella realizzazione di un sistema necessariamente portatile. Inoltre, questo tipo di soluzione in cui l’applicazione si appoggia direttamente sul layer HCI non è conforme alla specifica Bluetooth, e farebbe perdere la possibilità di apporre il marchio sopra il prodotto finale. Nonostante questa architettura sembri decisamente poco attraente, c’è in realtà un caso in cui risulta decisamente utile, ovvero quando, non avendo ancora familiarizzato abbastanza con lo standard, si vogliano usare gli strumenti software messi a disposizione dal costruttore.

Figura 3-7 : prima alternativa

L’architettura mostrata in Figura 3-8 presenta un sistema in cui lo slave B è realizzato secondo uno schema wholly embedded, ovvero con tutto lo stack che gira insieme all’applicazione sullo stesso chip, mentre i master mantengono una struttura a due processori host-host controller. In questa maniera migliorano sicuramente l’ingombro ed il consumo dei nodi casco, e per questo motivo da questo punto in poi non verranno nemmeno prese in considerazione architetture che prevedano la presenza di un host sui caschi, ma, se in questo modo per gli slave sono risolte le questioni di compliance Bluetooth, per quello che riguarda i master il problema resta aperto. Inoltre si pone un problema piuttosto gravoso, che consiste nella necessità di implementare sull’host i layer superiori dello stack. Quello che succede, infatti, è che ognuno dei layer presenti sui caschi vorrà instaurare una connessione logica con il suo omologo sul master, che ne dovrà essere di conseguenza munito. Per ovviare a questo inconveniente possiamo

pensare alla possibilità di usare lo stack già testato e certificato fornito dal produttore del chip Bluetooth, e di memorizzarlo sulla flash collegata al chip, pervenendo, insomma, alla proposta mostrata in Figura 3-9. Questo tipo di partizionamento, infatti, ci esonera dalla necessità di produrre il nostro proprio codice dello stack, essendo questo già tutto presente sul Bluecore. Questa architettura, però, costringe l’applicazione residente sull’host a gestire tutte le procedure necessarie per l’instaurazione controllo e disfacimento sia della piconet, che della scatternet. Inoltre, così facendo, e sarebbe proprio un peccato, non sfrutteremmo affatto le risorse di calcolo che il RISC integrato sul Bluecore continua ad offrirci mentre gestisce l’esecuzione del solo stack di protocollo.

Figura 3-9 : terza alternativa

Ferma restando la scelta sui nodi slave per i motivi esposti nella descrizione della prima architettura proposta, si può osservare che, nell’architettura in Figura 3-10, per quanto riguarda i nodi master, il partizionamento viene ora eseguito a livello di applicazione. Essa risulta infatti per così dire divisa in due parti, una residente sul chip e quindi controllata dalla virtual machine, l’altra sull’host, che eventualmente potranno comunicare mediante la porta seriale. In questo modo, otteniamo il duplice risultato di evitare il processo di qualificazione dello stack di protocollo e di evitare lo sperpero della potenza di calcolo disponibile a bordo del chip. Da questa corrispondenza fra partizionamento hardware e software emerge una naturale divisione dei compiti tra applicazione host e applicazione host controller: il modulo software imbarcato sul Bluecore si occuperà di instaurare la piconet e successivamente la scatternet, controllarle e distruggerle, mentre quello presente sull’host dovrà gestire i dati scambiati con i nodi slave e con i nodi appartenenti all’altra piconet, instradandoli opportunamente. In questo modo non soltanto è possibile raggiungere l’obiettivo prefissato per quanto riguarda il funzionamento della scatternet, ma si rende anche il sistema estremamente flessibile e adatto a modifiche future. La quantità e qualità delle elaborazioni che possiamo compiere dipende, infatti, esclusivamente dalla potenza del processore che viene scelto, rendendo eventualmente possibile un futuro upgrade della applicazione.

3.7 Scelta definitiva del partizionamento dello stack

Nel precedente paragrafo abbiamo analizzato varie alternative architetturali ed evidenziato le peculiarità per ognuna di esse. Si è visto che, per quanto riguarda lo sfruttamento del processore interno al chip BlueCore, la quarta alternativa risulta quella più efficiente ed il sistema host-host controller risulta più flessibile ad eventuali modifiche. Nonostante la sua efficienza, questa soluzione diviene molto

complessa per quanto riguarda la sua implementazione, ossia la scrittura dei comandi sotto forma di codici ad alto livello. Inoltre, dovendo gestire in questo modo tutti e tre i moduli Bluetooth, il lavoro si complica ulteriormente e ciò porta ad un prolungamento dei tempi di realizzazione. Ed infine, la capacità di calcolo dei moduli Bluetooth può risultare insufficiente a supportare la nuova applicazione scatternet quindi l’alternativa scelta non sarebbe più una strada percorribile. Bisognerebbe, dunque, ritornare a valutare le altre alternative, secondo le quali l’applicazione gira nell’host e i moduli Bluetooth eseguono soltanto lo stack di protocollo ed anche in questo caso i tempi di realizzazione si prolungherebbero ulteriormente.

I motivi suddetti hanno portato alla scelta della partizione dello stack in accordo con la prima alternativa, ossia quella in cui l’applicazione viene eseguita interamente dall’host, e la comunicazione tra host e host controller avviene a livello HCI. I moduli Bluetooth, quindi, sono esenti da ogni tipo di elaborazione dei comandi ricevuti, dovendo essi gestire soltanto l’assemblaggio dei pacchetti Bluetooth e la loro trasmissione. Tale scelta risulta vantaggiosa per il fatto che, dovendo prendere confidenza con lo standard Bluetooth, diventa opportuno sfruttare gli strumenti software messi a disposizione dal produttore per osservare il comportamento dei moduli a conseguenza dei comandi inviati da parte dell’host. In particolare, usando il programma Command Window e Watch Window, si possono inviare ai moduli dei comandi HCI ed inoltre si può osservare la sequenza degli eventi scaturiti da tali comandi. In questo modo si riescono ad interpretare tali eventi per poi agire di conseguenza inviando altri comandi ancora.

La scelta di far comunicare l’host e l’host controller a livello HCI e l’utilizzo del programma Command Window e Watch Window costituiscono la fase preliminare della realizzazione della scatternet. Tramite questo approccio, i moduli Bluetooth sono stati testati ed in particolar modo è stata osservata la loro capacità o meno di supportare determinati comandi utili nella fase di creazione della scatternet. Questo lavoro ha dato i suoi frutti, nel senso che ha reso possibile la comprensione di vari punti oscuri per quanto riguarda la lettura degli eventi

provenienti dai moduli Bluetooth. Tramite vari tentativi è stata determinata la giusta sequenza di comandi da inviare ai dispositivi per arrivare alla formazione della scatternet. Nonostante la sua efficacia in fase di testing dei dispositivi Bluetooth, il programma Command Window non offre la possibilità di inviare comandi sotto forma di codici HCI esadecimali, ma soltanto la denominazione dei comandi. In questo modo non è possibile vedere se i bit costituenti tali comandi sono stati inviati e ricevuti correttamente da parte dei moduli e di conseguenza non si possono individuare eventuali errori che pregiudicherebbero il risultato del lavoro. Fermo restando la scelta della prima alternativa architetturale, è opportuno utilizzare dei programmi tramite i quali si possono, manualmente, inviare i codici HCI dei comandi e ricevere i codici HCI degli eventi, in modo da esaminare a fondo il comportamento dei moduli e riuscire a controllare più agevolmente il funzionamento della rete. Nel prossimo capitolo, scelto l’approccio suddetto, verrà spiegato il modo in cui la scatternet è stata implementata.