6. Sperimentazione
n questo capitolo viene esposta la procedura che è stata seguita, nel testing del sistema, per assicurarsi che tutte le funzionalità richieste fossero effettivamente implementate e pienamente funzionanti.
Vengono quindi discussi i problemi riscontrati in questa fase, e si presentano le soluzioni che sono state adottate per risolverli.
I
6.1 Procedura
Per la scrittura del codice è stata seguita un approccio di tipo top-down, ossia si è suddivisa l’applicazione completa in blocchi funzionali indipendenti, che sono stati a loro volta scomposti fino a che non si è giunti ad ottenere delle unità idonee ad essere implementate. Un tale modo di procedere ha permesso non solo di isolare agevolmente le funzionalità da assegnare ad ogni thread, ma anche di procedere al testing di singole parti del sistema, senza doverne affrontare la complessità nella sua interezza.
Dapprima, quindi, si è valutato il comportamento del codec, prelevando dei campioni in ingresso da un semplice lettore CD connesso ai jack RCA della EZ-KIT Lite e rimandandoli in uscita su un paio di altoparlanti: vale a dire, si è realizzato un talkthrough. Poi è stata inserita una fase di missaggio dei campioni, in modo da capire se l’elaborazione poteva causare un deterioramento della qualità. In tal modo si è potuto valutare quale fosse la qualità percepita dell’audio campionato, e si é presa confidenza con le tecniche di gestione del codec tramite DMA.
Appurato che il codec forniva un audio di buona qualità, e che il suo controllo non presentava particolari problemi ne’ in sé, ne’ dal punto di vista dell’impiego di risorse di calcolo, l’attenzione si è spostata sulla gestione dell’interfaccia: si è quindi testata la funzionalità della porta UART ed è stata scritta una prima bozza del thread Control Unit, per mettere a punto sia il meccanismo di interruzione che preleva i comandi dalla periferica, sia il meccanismo di analisi/attuazione/risposta ai comandi stessi. Per fare questo l’interfaccia è stata simulata, in una sua versione provvisoria, tramite l’ambiente per l’analisi real time dei dati LabView, ed il transito dei frame lungo la linea seriale è stato controllato con un oscilloscopio. In figura 6.1 si può vedere l’aspetto dell’interfaccia simulata con LabView.
Figura 6.1: Interfaccia simulata con LabView
Il passo successivo è consistito nel creare un’applicazione che, pur lasciando sempre fuori la rete Bluetooth, ha riunito l’utilizzo del codec e la capacità di ricevere ed inviare comandi all’interfaccia: in conseguenza dei comandi ricevuti il sistema prelevava i campioni dal codec, li elaborava e li rimandava in uscita. Ovviamente, mancando la rete Bluetooth, gli ingressi relativi ai caschi sono stati simulati con delle sorgenti generiche (un lettore
CD ed una radio FM) connesse al codec, mentre le uscite sono state simulate con due altoparlanti; in tal modo si è verificato che i comandi inviati dall’interfaccia venivano opportunamente decodificati dall’applicazione residente sul DSP, che poi indirizzava nel modo voluto i flussi audio nelle relative code: su ogni canale (destro o sinistro) degli altoparlanti è stato possibile inviare un numero qualsiasi di altre sorgenti, opportunamente mixate, esattamente come di volta in volta veniva richiesto dall’utente che comandava l’interfaccia.
In questa fase l’interfaccia è stata connessa al DSP tramite la porta RS 232 della EZ-Kit Lite (che nel prototipo finale è impegnata dal BlueCore), in modo da separare la verifica della funzionalità dell’interfaccia dalla emulazione di una UART con la SPORT1. Anche queste prove non hanno evidenziato particolari difficoltà.
Per poter connettere il BlueCore si è quindi spostata l’interfaccia sulla UART emulata da SPORT1. Poiché come detto l’interfaccia è stata simulata con un’applicazione LabView, che gira su di un PC e comunica con l’esterno utilizzando lo standard RS 232, è stato necessario realizzare una piccola scheda (il cui schema è visibile in figura 6.2) per convertire i livelli elettrici UART ai livelli standard RS 232, prelevando ed inviando i dati dal connettore presente sulla EZ-KIT al PC. L’emulazione software di un protocollo asincrono con un hardware “nato” per essere sincrono non ha creato problemi di gestione del flusso dati: nella trasmissione è stato sufficiente inserire nei frames da inviare i bit di start e di stop richiesti per la sincronizzazione, mentre in ricezione si è dovuto far si che il bit di start arrivasse in parallelo sia alla linea di ricezione dati che al piedino di frame sync.
Tale piedino porta, nel protocollo seguito dalla SPORT, un segnale che indica al ricevitore l’arrivo di un frame dal trasmettitore, in modo sincrono al clock: in questo modo il ricevitore è svincolato dalla necessità di avere, sulla
linea di ingresso, un livello elettrico preciso, ma andrà ad effettuare il campionamento della linea solo quando disposto dal frame sync.
Figura 6.2: Schema elettrico della scheda ausiliaria utilizzata durante lo sviluppo.
Un problema in cui invece si è incorsi, è stato dato proprio dal livello di riposo della linea dati di trasmissione del DSP. Nella comunicazione UART, infatti, il livello di riposo della linea è essenziale: la linea deve, in condizioni di riposo, stazionare sul livello alto, ed è una transizione alto - basso a segnalare che sta arrivando un nuovo frame, e quindi si deve campionare la linea. Analizzando il livello sulla linea con un oscilloscopio si è scoperto (la cosa non era documentata) che la SPORT, dopo l’invio di un frame, mantiene come livello di riposo il livello del primo bit del frame appena trasmesso: dato che, appunto, in una comunicazione UART il primo bit del frame è sempre al livello elettrico basso (bit di start), questo si riflette nel mantenimento, da parte della SPORT, di un livello di riposo basso.
Per ovviare a questo inconveniente si è aggiunto, in testa ad ogni frame, un bit al livello elettrico alto, che chiameremo dummy start bit; in figura 6.3 si può vedere uno schema dei dati come dovrebbero transitare su una linea UART (a), i dati che si sono ottenuti con la linea SPORT senza apportare la necessaria correzione (b), ed i dati che transitavano in uscita dalla SPORT dopo aver introdotto il dummy start bit (c), inviando due frames con pattern 11001010 e 10001110.
Figura 6.3: Frames trasmessi sulla linea di connessione dell’interfaccia, nei tre casi di linea UART (a), UART emulata da SPORT senza dummy start bit (b) ed UART emulata da SPORT
con dummy start bit (c)
Come si vede, nel caso (b) la linea si porta al livello basso dopo aver trasmesso il bit di stop, perché il primo bit di ogni frame è il bit di start, che è al livello basso. Dal punto di vista del ricevitore questo causa ben due problemi:
1. Questa stessa transizione viene interpretata come un bit di start, non seguito poi, con ragionevole certezza, da un bit di stop. Il ricevitore asincrono campiona quindi la line memorizzando il frame 00000000, poi interpreta la mancanza del bit di stop come un errore, e lo segnala.
2. Non saranno riconosciuti dal ricevitore altri bit di start fino alla transizione indicata dalla freccia blu: a quel punto sarà campionato e memorizzato il frame 00111010, ovvero un frame diverso da quello trasmesso (e poi sarà segnalato un altro errore di sincronismo dovuto alla mancanza del bit di stop).
Concludendo, nell’esempio, invece di ricevere i due frames trasmessi (11001010 e 10001110) saranno ricevuti i seguenti tre frames: 11001010, 00000000 e 00111010, e saranno segnalati due errori. Quindi per trasmettere un frame che, dal punto di vista della UART, contiene 10 bit (1 start, 8 dati, 1 stop), si sono dovuti trasmettere 11 bit (1 dummy start, 1 start, 8 dati, 1 stop), abbassando il data rate reale della linea. Ciò non rappresenta però un inconveniente serio (anche se l’interfaccia viene controllata con un meccanismo ad interruzione), dato che il transito di dati sulla linea è molto sporadico.
Superato questo inconveniente si è passati alla fase successiva del lavoro, inserendo nel sistema il transceiver Bluetooth, realizzando lo schema di fig 6.4.
Figura 6.4: Schema del dimostratore utilizzato per le prove
Il BlueCore è stato utilizzato all’interno del modem Casira (visibile in figura 6.5), prodotto, come il chipset, dalla CSR. L’uso del Casira ha dato la possibilità di interfacciarsi in maniera semplice col chip BlueCore02, fornendo 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 vengono effettuati sfruttando un software di utilità fornito col chip, chiamato BlueFlash, che gira in ambiente Windows.
Le impostazioni del chip sono invece 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à dei frame della UART, scegliere l’interfaccia per l’host controller, scegliere se mappare l’audio sulla PCM o, come è stato
fatto in questo sistema, sul layer di trasporto HCI. Infine, cosa che si è rivelata molto utile in fase di debug del software, i leds presenti sul Casira hanno consentito di controllare visivamente lo stato di operatività del chip, ovvero se fosse in “idle”, quante connessioni RFCOMM o SCO fossero attive.
Figura 6.5: Viste superiori, aperto e chiuso, del modem Casira. Il BlueCore è visibile all’interno dell’ovale bianco, mentre i leds all’interno degli ovali rossi.
Innanzi tutto si è resa necessaria una fase di analisi dei comandi e degli eventi inviati dal BlueCore al DSP, che non erano ben documentati: con un'applicazione in LabView, connettendo il Casira al PC tramite la linea RS 232 si è ricostruita la struttura ed il contenuto dei messaggi inviati e ricevuti sulla linea seriale dal BlueCore in corrispondenza di ogni comando, per ognuno dei due headsets utilizzati, che chiameremo blu ed argento. Nelle tabelle che seguono sono riportati i byte che compongono i pacchetti in corrispondenza di ogni comando od evento.
Auricolare Argento
Indirizzo: 000A00D90000BC05
NOME COMANDO
STRINGA INVIATA
NOME EVENTO STRINGA RICEVUTA
RESET *** *** 040F 0400 0000 00
AG_START_R
EQ 0100 FC07 CD03
0000 0000 00 AG_START_CFM 04FF 09CD 0400 0100 0000 0103
AG_INQUIRY _REQ
0100 FC0F CD07 0002 0004 0010 0020 0004 0400 00
1) AG_INQUIRY_RE SULT_IND 2) AG_INQUIRY_CO
MPLETE_CFM
1) 04FF 4DCD 2600 0300 0000 05BC D900 0A00 0000 0000 2000 0404 1B00 5200 6500 6D00 6F00 7400 6500 2000 6E00 6100 6D00 6500 2000 6E00 6F00 7400 2000 6400 6900 7300 6300 6F00 7600 6500 7200 6500 6400 0000
2) 04FF 07CD 0300 0500 0100 AG_PAIR_RE
Q 0100 FC11 CD08 0007 0000 0005 BCD9 000A 0001 0010 00
AG_PIN_CODE_REQUEST
_IND 04FF 0DCD 0600 0800 0000 05BC D900 0A00
AG_PIN_COD
E_RES 0100 FC2F CD17 0009 0000 0005 BCD9 000A 0004 0030 0030 0030 0030 0000 0008 0002 0000 0005 BCDE BF02 0017 0003 00E3 BF02 0000 00
1) Warning : remote low power mode not enabled
2) AG_PAIR_CFM (contiene la link key : in questo caso è : 0014 002F 0022 0015 006F 0033 00BA 008D 0091 000D 001E 009D 0069 00C1 00D9 007D
1) 04FF 09CD 0400 1E00 0000 1300 2) 04FF 2FCD 1700
0A00 0100 0000 05BC D900 0A00 1400 2F00 2200 1500 6F00 3300 BA00 8D00 9100 0D00 1E00 9D00 6900 C100 D900 7D00
AG_CONNEC T_AS_MASTE
R_REQ
0100 FC21 CD10 000D 0000 0005 BCD9 000A 000F 0001 0001 0000 0000 0000 0000 0000 0000 0008 11
1) Warning : remote low power mode not enabled
2) AG_RFCOMM_CO NNECTION_STAT US_IND
(connection complete)
3) Warning : local low power mode not enabled
1) 04FF 09CD 0400 1E00 0100 1300 2) 04FF 09CD 0400
1000 0100 0000 3) 04FF 09CD 0400
1E00 0100 1000
AG_CREATE_
SCO_REQ (HANDLE 1)
0100 FC09 CD04
0011 0001 0080 00 DATI SCO ***
AG_SCO_DIS CONNECT_RE Q (HANDLE 1)
0100 FC07 CD03 0014 0001 00
AG_SCO_CONNECTION_
STATUS_IND (Disconnect)
04FF 0BCD 0500 1200 0100 0300 2E00 AG_RFCOMM
_DISCONNEC T_REQ
0100 FC09 CD04
0011 0001 0080 00 1) AG_RFCOMM_CO NNECTION_STAT US_IND
1) 04FF 09CD 0400 1000 0100 0300 2) 04FF 09CD 0400
(HANDLE 1) (Disconnect) 2) Error: remote device
address not recognized
1E00 0000 1400
AG_FLUSH_T RUSTED_DEV ICES_REQ (HANDLE 1)
0100 FC07 CD03
001F 0000 00 AG_FLUSH_TRUSTED_D
EVICES_CFM 04FF 07CD 0300 2000 1500
Auricolare Blu
Indirizzo: 000A00D90000C518 NOME
COMANDO STRINGA
INVIATA NOME EVENTO STRINGA RICEVUTA
RESET *** *** 040F 0400 0000 00
AG_START_R
EQ 0100 FC07 CD03
0000 0000 00 AG_START_CFM 04FF 09CD 0400 0100 0000 0103
AG_INQUIRY
_REQ 0100 FC0F CD07 0002 0004 0010 0020 0004 0400 00
3) AG_INQUIRY_RE SULT_IND 4) AG_INQUIRY_CO
MPLETE_CFM
3) 04FF 4DCD 2600 0300 0000 05BC D900 0A00 0000 0000 2000 0404 1B00 5200 6500 6D00 6F00 7400 6500 2000 6E00 6100 6D00 6500 2000 6E00 6F00 7400 2000 6400 6900 7300 6300 6F00 7600 6500 7200 6500 6400 0000
4) 04FF 07CD 0300 0500 0100 AG_PAIR_RE
Q 0100 FC11 CD08 0007 0000 0005 BCD9 000A 0001 0010 00
AG_PIN_CODE_REQUEST
_IND 04FF 0DCD 0600 0800 0000 05BC D900 0A00
AG_PIN_COD E_RES
0100 FC2F CD17 0009 0000 0005 BCD9 000A 0004 0030 0030 0030 0030 0000 0008 0002 0000 0005 BCDE BF02 0017 0003 00E3 BF02 0000 00
3) Warning : remote low power mode not enabled
4) AG_PAIR_CFM (contiene la link key : in questo caso è : 0014 002F 0022 0015 006F 0033 00BA 008D 0091 000D 001E 009D 0069 00C1 00D9 007D
3) 04FF 09CD 0400 1E00 0000 1300 4) 04FF 2FCD 1700
0A00 0100 0000 05BC D900 0A00 1400 2F00 2200 1500 6F00 3300 BA00 8D00 9100 0D00 1E00 9D00 6900 C100 D900 7D00
AG_CONNEC T_AS_MASTE
R_REQ
0100 FC21 CD10 000D 0000 0005 BCD9 000A 000F 0001 0001 0000 0000 0000 0000 0000 0000 0008 11
4) Warning : remote low power mode not enabled
5) AG_RFCOMM_CO NNECTION_STAT US_IND
4) 04FF 09CD 0400 1E00 0100 1300 5) 04FF 09CD 0400
1000 0100 0000 6) 04FF 09CD 0400
1E00 0100 1000
(connection complete)
6) Warning : local low power mode not enabled
AG_CREATE_
SCO_REQ (HANDLE 1)
0100 FC09 CD04
0011 0001 0080 00 DATI SCO ***
AG_SCO_DIS CONNECT_RE Q (HANDLE 1)
0100 FC07 CD03 0014 0001 00
AG_SCO_CONNECTION_
STATUS_IND (Disconnect)
04FF 0BCD 0500 1200 0100 0300 2E00 AG_RFCOMM
_DISCONNEC T_REQ (HANDLE 1)
0100 FC09 CD04
0011 0001 0080 00 3) AG_RFCOMM_CO NNECTION_STAT US_IND
(Disconnect) 4) Error: remote device
address not recognized
3) 04FF 09CD 0400 1000 0100 0300 4) 04FF 09CD 0400
1E00 0000 1400
AG_FLUSH_T RUSTED_DEV ICES_REQ (HANDLE 1)
0100 FC07 CD03 001F 0000 00
AG_FLUSH_TRUSTED_D EVICES_CFM
04FF 07CD 0300 2000 1500
Gli indirizzi dei due headsets sono stati ricavati dall'evento AG_INQUIRY_RESULT_IND.
Appurato che i comandi e gli eventi avevano il formato atteso, e che il software riusciva a gestirli correttamente, si è passati al controllo della UART in DMA, in particolare al testing di varie modalità di trasferimento allo scopo di determinare quale potesse essere la piú adatta. Purtroppo si sono riscontrati problemi sia nella fase di ricezione che in quella di trasmissione: la ricezione (impostata, come detto, in autobuffer mode) ha creato noie riguardo alla memorizzazione dei campioni audio (ed in generale di tutti i dati che il compilatore considerava a 32 bit) in memoria: infatti, seppure gli interi (int o unsigned int) standard per il VisualDSP++ vengono considerati numeri memorizzati su 32 bit, la memoria del Blackfin è organizzata in parole da 16 bit; ci si è accorti, quindi che le due parole da 16 bit, MSW e LSW, venivano invertite all'atto della loro scrittura in memoria, rendendo non piú significativo il dato. La soluzione adottata è stata quella di ricorrere, nella dichiarazione delle variabili, alla direttiva di allineamento
pragma align, che forza il compilatore ad allocare i dati nel modo indicato.
Una soluzione a livello di codice, pure adottabile, è stata scartata perché avrebbe assorbito risorse di calcolo inutilmente, anche se non si sarebbe intaccata la funzionalità del sistema.
Nella trasmissione dal DSP al BlueCore, invece, si è incontrato un bug relativo all'impostazione dei trasferimenti DMA: nel settare la lunghezza dei buffer da trasferire, ci si è resi conto che la lunghezza da impostare (in numero di locazioni) doveva essere maggiorata di quattro unità. Non si è trovata, ne' in letteratura ne' con la logica, una spiegazione di questo problema, ma semplicemente ci si è adeguati ad esso nell'impostazione dei descrittori (campo X_Count).
Nel risolvere questi problemi si sono fatte le seguenti prove:
• si è fatto un pairing, cioè si è connesso un headset con il BlueCore, facendo si che il comando partisse dall’interfaccia ed inviando al BlueCore il codice PIN memorizzato nel DSP;
• si è eseguito, con le stesse modalità, il pairing di entrambi gli headsets;
• si è cancellato il database degli headsets parificati, si è eseguito un secondo pairing per entrambi gli headsets, e si sono attivate e disattivate entrambe le connessioni RFCOMM.
• si sono create e distrutte entrambe le connessioni SCO, indirizzando i flussi audio secondo i comandi provenienti dall’interfaccia, ed operando sui campioni sia in ingresso che in uscita tutte le relative elaborazioni di missaggio.
La risoluzione di tutti i problemi ha reso necessaria la correzione di quasi tutti i threads che compongono il software del sistema: durante la fase in cui si sono effettuate le inquiry, i pairing ed attivati o distrutti i link RFCOMM ed SCO si è intervenuti sui threads Control Unit ed UART Writer, mentre
quando si è avuto a che fare con la trasmissione e la ricezione di dati SCO si è intervenuti sui threads Audio Manager ed UART Reader.
Infine è stata progettata la scheda aggiuntiva, quindi prima si sono disegnati gli schemi elettrici con l'applicazione Capture CIS di OrCAD, poi si è disegnato, per ogni componente, il relativo footprint, cioè l'impronta, in dimensioni reali, che il componente occupa sulla scheda. Tramite l'applicazione Layout Plus di OrCAD si è ricavata la "traduzione" dello schema elettrico in layout, e si sono effettuati il placement ed il routing, adottando una tecnologia a doppia faccia. Nel momento in cui si è resa disponibile la scheda stampata, sono stati saldati i componenti. Si fa notare che, per tutti i componenti passivi e gli integrati per cui è stato possibile, si è fatto ricorso a dispositivi a montaggio superficiale, per diminuire il piú possibile gli ingombri della scheda.
