Creazione di applicazioni audio Bluetooth a basso costo con MCU a 32 bit

Il Bluetooth e le applicazioni audio erano praticamente fatti l'uno per le altre. Il successo di mercato registrato dal Bluetooth nel primo decennio è stato da attribuirsi quasi interamente all'integrazione di questa tecnologia nelle cuffie audio. Quando sono entrati in scena gli smartphone, la tecnologia Bluetooth era ancora una scelta naturale, trovando agevolmente spazio sul die di qualsiasi chipset di smartphone. Le persone adorano ascoltare la musica dal proprio smartphone.

Tuttavia il Bluetooth e gli smartphone continuano ad evolvere, seguendo un percorso in qualche modo inverso rispetto al normale susseguirsi degli eventi, e le applicazioni hanno faticato a tenere il passo. Ma questa situazione sta cambiando: sta rapidamente tramontando l'era in cui un dispositivo Bluetooth master dialogava con un dispositivo Bluetooth slave.

Per i progettisti, questo si traduce in più protocolli, più connessioni, più dispositivi e l'alba di un nuovo mondo di applicazioni audio. Gli utenti di smartphone vogliono più scelte e la tecnologia Bluetooth è pronta.

Il punto di partenza: A2DP

Il profilo Bluetooth A2DP (Advanced Audio Distribution Profile) da oltre un decennio permette di dotare un'ampia gamma di dispositivi di comodo audio stereo wireless. Tuttavia i consumatori oggi vogliono utilizzare i propri smartphone per controllare l'intrattenimento audio in modi in origine non immaginabili.

Quando combinati con altri profili, ad esempio AVRCP (Audio/Video Remote Control Profile), gli smartphone possono essere utilizzati come telecomando wireless per altri dispositivi audio Bluetooth presenti in casa e le applicazioni possono diventare alquanto sofisticate.

Sebbene pensate per un uso senza soluzione di continuità per l'utente finale, queste applicazioni pongono al progettista importanti sfide per la certificazione e lo sviluppo di software, in particolare quando implementate su accessori che richiedono l'interoperabilità nell'ambito di un ecosistema.

I progettisti hanno due opzioni architetturali. Nell'ultimo decennio l'architettura predominante richiedeva che il modulo svolgesse la maggior parte delle funzioni (accoppiamento, connessione e streaming audio) nell'hardware. In altre parole, il modulo Bluetooth era un codec audio cablato per l'esecuzione di queste funzioni. La seconda opzione architetturale prevede invece che tutte le funzioni vengano virtualmente eseguite nel software; ed è qui che entra in gioco l'MCU a 32 bit. Con l'implementazione dello stack Bluetooth nel software, la radio viene trasformata in un layer molto sottile dell'architettura. Ciò consente ai progettisti di accedere al flusso di dati in qualsiasi luogo e in qualsiasi momento e per un gran numero di configurazioni.

I tradizionali moduli Bluetooth non permettono di utilizzare simultaneamente i profili SPP (Serial Port Profile) e A2DP (Advanced Audio Distribution Profile). Abilitando l'accesso software allo stack del protocollo Bluetooth, i progettisti possono creare applicazioni in grado di mantenere più connessioni dispositivo al flusso audio per l'ascolto, ma anche per il controllo del flusso e altre funzioni normalmente non correlate all'audio. In altre parole, un flusso audio e un flusso di dati di controllo operano simultaneamente senza interrompersi reciprocamente.

Combinazione di audio e controllo dati

Un esempio di immediata comprensione potrebbe essere una lampada da scrivania combinata con un altoparlante, che consentisse agli utenti di controllare i livelli di illuminazione tramite lo smartphone mentre ascoltano la musica. Un'estensione sofisticata di questa applicazione potrebbe permettere il controllo di un impianto di illuminazione (colore, intensità, risposta alla musica, e molto altro ancora), nonché il controllo del flusso audio, tramite smartphone. Con l'aggiunta del concetto di domotica all'applicazione, l'aspetto del controllo si amplia a comprende il controllo di termostati, macchine del caffè, apriporta di garage, e altri elettrodomestici abilitati per Bluetooth, rispetto a quello che una volta era un codec audio tradizionale.

Il controllo Bluetooth aggiunge a queste applicazioni un vantaggio di sicurezza, dal momento che il flusso di dati può essere configurato per essere indipendente dall'Internet delle cose (IoT). Sono poche le persone disposte a esporre il semplice processo di controllo dell'apertura del proprio garage alle incertezze del funzionamento sul Cloud, cosa che con ogni probabilità accadrebbe, ad esempio, con una soluzione Wi-Fi.

La combinazione di audio e controllo dati in un'applicazione che già dispone di più profili che operano simultaneamente espande ulteriormente la nuova applicazione. Nel dominio dell'intrattenimento audio, un concetto abilitato dal software denominato “break-in” permette a più dispositivi di controllare lo stesso flusso audio. Ad esempio, ad una festa gli ospiti potrebbero scegliere a turno la propria musica preferita dalla stessa libreria di contenuti audio con funzionalità Bluetooth. L'attivazione di una modalità “juke-box” potrebbe consentire agli utenti finali di aggiungere i propri brani preferiti ad una playlist. Grazie alla soluzione MCU, la modalità “break-in” permette ad un massimo di sette smartphone di controllare lo stesso sistema audio con controlli e flussi di dati indipendenti e differenti.

L'unione di audio e controllo

Nonostante Bluetooth SIG abbia creato e ratificato più di 30 profili, i quattro di seguito riportati con ogni probabilità saranno i più importanti nell'evoluzione iniziale nel mondo delle nuove applicazioni caratterizzate da audio+controllo Bluetooth.

• SPP (Serial Port Profile): sostituzione standard per la trasmissione dati RS-232 wireless.
• A2DP (Advanced Audio Distribution Profile): il profilo più comune per lo streaming di audio multimediale. Effettua lo streaming di audio tramite codec SBC e può supportare i codec di compressione MPEG e AAC.
• AVRCP (Audio Video Remote Control Profile): profilo di controllo remoto standardizzato per televisori, impianti home theater, e così via. Comunemente utilizzato in combinazione con A2DP. Una funzione ratificata di recente è la sincronizzazione audio: ad esempio, quando il volume viene cambiato sul dispositivo, viene regolato di conseguenza anche sul sistema da questo controllato.
• HFP (Hands-Free Profile): telefonate remote.

In un'implementazione software, possono essere attivi più profili simultaneamente, cosa che offre al progettista una grande flessibilità per la creazione di nuove applicazioni. In altre parole, l'integrazione di un flusso di dati con il flusso audio permette di creare sistemi avanzati.

La fase di progettazione deve prevedere anche l'emulazione, il collaudo e (da non dimenticare con la tecnologia Bluetooth) la certificazione. Un sistema di sviluppo completo, pertanto, deve andare ben oltre l'audio e integrare le funzionalità per il controllo di display, pulsanti, LED, microfoni e musica. Deve inoltre includere la capacità DSP per le funzioni di elaborazione audio. L'aspetto del controllo del sistema, e non semplicemente della musica, offre un motivo molto valido per utilizzare un MCU a 32 bit.

Come punto di partenza per illustrare i punti base della progettazione per creare questo tipo di funzionalità, nella Figura 1 sono riportati il percorso dati e gli elementi principali di un sistema audio Bluetooth base.

Guardando questa illustrazione dal punto di vista di un nuovo set di applicazioni audio+controllo, il lato sorgente è il telefono cellulare, che invia dati codificati (audio e controllo) che possono essere crittografati. I dati raggiungono il layer in banda base (una radio Bluetooth). Il flusso di dati risale lo stack di protocollo sul lato sink, che può essere qualsiasi dispositivo o apparecchio intelligente precedentemente esaminato.

La soluzione software include sia lo stack multiprofilo che un layer di applicazione che può essere modificato nel codice sorgente. Lo stack gestisce la comunicazione del profilo e può interagire con una serie di elementi applicativi aggiuntivi, come decoder audio, filtri digitali, conversione della frequenza sorgente e funzioni di controllo. Per l'audio sono disponibili più decoder che supportano lo streaming audio Bluetooth A2DP, come SBC, AAC e MP3. Questa soluzione modulare permette ai produttori di dispositivi di differenziare le potenziali soluzioni in base alle funzionalità, ai controlli e ai costi della memoria.



Kit di sviluppo fornitori

La creazione di starter kit e kit di sviluppo per sistemi sul lato sink del collegamento di comunicazione è un'impresa che presenta notevoli difficoltà. Se da un lato semplificano lo sviluppo di applicazioni per i progettisti, i test di compatibilità e interoperabilità rappresentano un aspetto di importanza critica per qualsiasi fornitore di MCU che intenda offrire tali kit.

Esistono vari sistemi operativi per dispositivi mobili (es. Android, IOS di Apple, Embedded Windows di Microsoft e Blackberry), ciascuno con varie versioni del sistema operativo. Per garantire l'usabilità del prodotto per l'utente finale, il fornitore del kit deve eseguire centinaia di test di compatibilità e di interoperabilità. La garanzia che il progetto supererà questi test con rilavorazione minima se non nulla deve essere tra i più importanti fattori nella scelta di un kit da parte dei progettisti.

Microchip Technology è uno dei protagonisti di questo spazio di progettazione. Attualmente utilizza i propri dispositivi PIC32MX3 e PIC32MX4 nei propri kit di sviluppo audio Bluetooth. La Figura 2 illustra la configurazione hardware di base.



Uno specifico esempio è il kit di sviluppo audio Bluetooth dell'azienda DV320032. È alimentato da un dispositivo PIC a 32 bit di fascia media a 100 MHz con un massimo di 100 I/O e 512 kB di flash/128 kB di RAM. Nel kit base è integrata una scheda figlia HCI Bluetooth che supporta il transceiver Bluetooth CSR8811 di Cambridge Silicon Radio (sono disponibili anche moduli di costo inferiore). Sono inoltre incluse una scheda figlia DAC con un DAC a 192 KHz a 24 bit e uscita cuffie, interfacce USB Host/Device, un display LCD a colori da 2" e funzioni di controllo pulsanti. Per semplificare il lavoro del progettista, il kit permette anche numerose funzioni quali l'opzione adattatore di autenticazione Apple, un'interfaccia di debug e una memoria flash SPI.

Un modulo di interfaccia programmabile (PIM) situato sull'MCU fornisce agli sviluppatori la possibilità di sostituire il processore stesso senza perdere prezioso tempo di progettazione. Offre inoltre ai progettisti la flessibilità di sostituire in futuro l'MCU standard con dispositivi a prestazioni superiori o costi inferiori.

La disponibilità del firmware è sempre un elemento chiave per i kit di sviluppo. Microchip fornisce il firmware indicato nella Figura 3.



Microchip offre inoltre uno starter kit di fascia più alta basato sul suo rinomato MCU a 32 bit e 200 MHz PIC32MZ2048ECH144. Lo starter kit per connettività embedded DM320006 PIC32MZ può essere abbinato ad un altro sistema per abilitare le funzionalità Bluetooth. La scheda di espansione multimediale 2 (DM320005-2) comprende un'unità di grafica senza controller, un display WQVGA da 4,3", controllo pulsanti multi-touch capacitivo proiettato (PCAP), videocamera VGA, Wi-Fi, modulo HCI Bluetooth, codec audio stereo a 24 bit basato su AK4953 di AKM Semiconductor, accelerometro a 3 assi e un sensore di temperatura. Una funzionalità dimostrativa da utilizzare con il framework software MPLAB Harmony di Microchip è in corso di integrazione, per supportare le applicazioni audio e dati Bluetooth.

Qual è la soluzione giusta?

La grande complessità delle applicazioni audio+controllo Bluetooth può creare perplessità negli sviluppatori in merito a come iniziare lo sviluppo. Il dispositivo critico è, naturalmente, lo stesso MCU. Come precedentemente indicato, gli MCU a 32 bit e i relativi set di istruzioni a 32 bit sono l'ideale per combinare audio e controllo contemporaneamente. Come primo passo per individuare il kit da utilizzare, gli sviluppatori possono fare riferimento alla Tabella 1, che descrive le applicazioni e i relativi requisiti di memoria e MIPS.

Descrizione	Requisiti di risorse		Picco MIPS
	Flash (kB)	RAM (kB)
Stack Bluetooth (A2DP+AVRSPP+SBC) + supporto connessione USB tipo A audio Android Open Accessory e audio Samsung con supporto connessione USB mini B.	271,734	38,8	~30
Stack Bluetooth (A2DP+AVRCP+SPP+decoder AAC) + grafica. Questa dimostrazione utilizza il decoder audio AAC di qualità superiore al posto del decoder SBC.	251,5	34,9	~65
Stack Dati Bluetooth (solo SPP). Questa dimostrazione solo dati, senza audio, non fornisce supporto audio USB.	139,6	7,12	~8
Stack Bluetooth (A2DP+AVRCP+SPP+decoder SBC) + grafica.	190,58	34,6	~30
Stack Bluetooth (A2DP+AVRCP+SPP+AAC) + supporto connessione USB tipo A audio Android Open Accessory e audio Samsung con supporto connessione USB mini B. Questa dimostrazione utilizza il decoder audio AAC di qualità superiore al posto del decoder SBC.	332,7	39,7	~65

Tabella 1: Esempi di requisiti di risorse per le applicazioni, quali applicazione, stack Bluetooth ed elementi del display grafico (per gentile concessione di Microchip Technology).

Nella prima colonna (Descrizioni) sono indicati i profili Bluetooth e le altre applicazioni in esecuzione. Si tratta solo di esempi per scopi dimostrativi, ma nel complesso attestano che i valori di memoria e MIPS possono variare significativamente dall'applicazione più semplice (solo stack di dati Bluetooth) a quella più esigente (profili multipli e decoder ACC di alta qualità).

Conclusione

Una nuova era di sviluppo Bluetooth che combini il controllo dei dati con l'audio agevolerà la crescita di molte nuove applicazioni che utilizzano più profili Bluetooth attivati simultaneamente, più punti di controllo e più connessioni. Queste applicazioni possono essere difficili da sviluppare, soprattutto perché devono superare i test di interoperabilità e compatibilità Bluetooth. Molte di queste applicazioni inoltre rendono indispensabile l'utilizzo di un MCU a 32 bit, non tanto per la profondità dei dati quanto per le risorse del set di istruzioni.

I kit di sviluppo e le soluzioni firmware offerte dai fornitori di silicio riducono significativamente l'impegno in fase di progettazione, ma non esiste un'unica soluzione in grado di soddisfare tutte le esigenze. Gli sviluppatori devono scegliere con attenzione la soluzione più adatta alla propria applicazione, prendendo in considerazione tanto la disponibilità del firmware quanto le prestazioni hardware.

Per ulteriori informazioni sui componenti citati in questo articolo, utilizzare i collegamenti forniti per l'accesso alle pagine di prodotto sul sito DigiKey.

(Nota del redattore: questo articolo si basa su una presentazione di Michael Skow, Applications Engineering Group Lead della Divisione MCU32 di Microchip Technology. Skow terrà la presentazione nel corso dell'edizione 2014 della MASTERs Conference di Microchip, che avrà luogo ad agosto a Phoenix, in Arizona)