Una breve descrizione dello standard Bluetooth ed il suo impiego in applicazioni embedded. Come esempio verrà descritta la realizzazione di una applicazione di cable replacement per il controllo remoto di I/O.
Tra i sistemi di comunicazione dati wireless, i dispositivi Bluetooth presentano molte caratteristiche interessanti: offrono una discreta velocità, una buona affidabilità e sicurezza nella comunicazione, ed inoltre sono estremamente diffusi (circa un miliardo di dispositivi) e disponibili in molti tipi di apparati dai PC ai PDA fino ai telefoni cellulari. Tutte queste caratteristiche lo rendono adatto in numerose applicazioni, in particolare di tipo industriale, di remotizzazione sensori o di cable replacement di applicazioni legacy. In questo articolo, dopo una breve esposizione delle caratteristiche dello standard, saranno descritti alcuni moduli di interfaccia Bluetooth adatti ad essere utilizzati nei sistemi embedded. Quindi, vedremo una applicazione di cable replacement d’esempio in cui interfacceremo un modulo bluetooth con un microcontrollore PIC18F2550 per controllare degli I/O. L’applicazione potrà essere usata con un qualsiasi programma di comunicazione da terminale su PC o PDA/Smartphone, o perfino su un telefono cellulare, se provvisto di un programma adatto (ad esempio sviluppato in Java).
LO STANDARD BLUETOOTH
Bluetooth è una tecnologia di comunicazione wireless a corto raggio nata con l’obiettivo di garantire l’interoperabilità tra dispositivi di tipo molto diverso tra loro - PC, PDA, telefoni cellulari, periferiche - nonché di produttori diversi, richiedendo inoltre bassi consumi rispetto ad altre tecnologie wireless. I dispositivi Bluetooth operano nella banda ISM (Industrial Scientific Medical) dei 2.4 GHz: il sistema RF utilizza una portante FHSS (Frequency Hopping Spread Spectrum) la cui frequenza varia continuamente tra i 79 canali disponibili in modo da diminuire le interferenze ed i fenomeni di fading. Ciò permette ad esempio di rendere possibile la coesistenza (almeno in via teorica) tra dispositivi Bluetooth e Wi-Fi. La tecnica AFH (Adaptive Frequency Hopping), introdotta a partire dalla versione 1.2, ha portato ad un ulteriore miglioramento in tal senso. Un canale RF è condiviso in un dato istante da un gruppo di dispositivi Bluetooth sincronizzati da un clock comune e da uno schema di hopping (salti di frequenza): il dispositivo che fornisce il riferimento è detto master, mentre gli altri sono detti slave. Tale insieme di dispositivi forma una piconet: essa comprende un master ed un massimo di 7 slave attivi. I dispositivi così sincronizzati cambiano la frequenza della portante fino a 1600 volte al secondo: ciò permette di diminuire la probabilità di intercettazioni delle comunicazioni da parte di dispositivi non autorizzati.
Topologia delle reti Bluetooth
La topologia di base di una rete di dispositivi Bluetooth è una piconet: in essa il dispositivo master comunica con gli slave mediante connessioni point-to-point o point-to-multipoint; gli slave non comunicano fra loro direttamente ma tramite il master.
Un dispositivo Bluetooth può essere coinvolto contemporaneamente in più di una piconet sulla base di una suddivisione temporale: in questo caso la piconet è detta scatternet. Notiamo che un dispositivo può essere master di una sola piconet. In figura 1 sono raffigurati due esempi di topologie piconet e scatternet.
Bluetooth è una tecnologia di comunicazione wireless ad-hoc: è necessario perciò un insieme di procedure operative atte a formare una piconet in maniera da rendere possibile la comunicazione tra i dispositivi.
Le procedure principali sono due:
- Discovering procedure
- Paging procedure
La discovering procedure viene utilizzata da un dispositivo Bluetooth per rilevare altri dispositivi (purchè questi siano disponibili ad essere rilevati: discoverable). La paging procedure viene usata da un dispositivo Bluetooth per stabilire una connessione con un altro specifico dispositivo, purchè quest’ultimo sia nello stato di page scanning. Ultimata la paging procedure, un dispositivo può trovarsi in diversi modi operativi tra cui:
- Connected mode
- Parked state
Nel connected mode, i dispositivi sono attivi e connessi fra loro così da poter comunicare. Un dispositivo può uscire da questo modo o sconnettendosi dal canale fisico o entrando nel parked state. Nel parked state il dispositivo rimane connesso alla piconet, ma non può comunicare con gli altri dispositivi: può, però ritornare attivo mediante la procedura di unparking invocata dal master. In tal modo è possibile realizzare piconet con più di 7 slave che vengono attivati quando necessario senza dover ripetere la procedura di connessione.
La sicurezza e la procedura di pairing
Il protocollo Bluetooth fornisce diversi strumenti per garantire la sicurezza delle comunicazioni. Ogni dispositivo Bluetooth è innanzi tutto fornito di un indirizzo unico che lo identifica, denominato BD_ADDR (Bluetooth Device Address): un numero di 48 bit fornito sotto la supervisione dell’IEEE, simile al MAC dei dispositivi Ethernet. Per permettere la connessione fra due dispositivi Bluetooth è sempre necessario (almeno all’atto della prima connessione) effettuare la procedura di pairing: in essa i dispositivi utilizzano un numero PIN (Personal Identification Number), ricavato da una stringa scelta dall’utente (passkey) o memorizzata nel firmware del dispositivo nel caso di sistemi privi di interfaccia utente. Sulla base del PIN, del BD_ADDR dell’altro dispositivo e di un numero casuale, viene innescata una procedura al termine della quale viene generata un link key che sarà memorizzata dai due dispositivi in modo da autenticarli. In aggiunta è possibile utilizzare una connessione crittografata mediante una procedura che genera una encription key sulla base di una link key preesistente. Vedremo, quando tratteremo l’applicazione d’esempio, come effettuare in pratica la procedura di pairing.
I layer dello stack Bluetooth
Lo stack Bluetooth è piuttosto complesso: in figura 2 ne possiamo vedere una rappresentazione semplificata in cui sono raffigurati solo i livelli ed i servizi di maggior interesse per i nostri scopi.
Possiamo innanzitutto distinguere i livelli tra:
- Controller layers: sono i livelli implementati nell’interfaccia Bluetooth vera e propria, ad esempio un adattatore USB.
- Host layers: i livelli implementati nel dispositivo host, come un PC o un PDA.
Vedremo però che, negli adattatori Bluetooth per sistemi embedded, alcuni, se non tutti i layer host, saranno implementati direttamente negli stessi, sia per semplificare lo sviluppo di applicazioni che per sopperire alla scarsità di risorse hardware dei dispositivi host. Esaminiamo ora brevemente i compiti dei vari layer con i principali protocolli associati. I controller layers sono i seguenti:
Radio Frequency: si occupa della trasmissione e ricezione dei pacchetti sul canale fisico RF.
- Baseband: si occupa della gestione dell’accesso al mezzo di trasmissione. Utilizza il link control protocol (LC) per effettuare il controllo di flusso e la ritrasmissione dei dati in caso di errore.
- Link Manager: oltre che della creazione e gestione dei link logici (mediante i quali sono trasportati i dati), si occupa delle operazioni di discovery di altri dispositivi Bluetooth, o di connessione (paging) con gli stessi, nonché di rendere il dispositivo discoverable o disponibile ad accettare connessioni. Da questo livello è inoltre gestito il pairing tra dispositivi.
Tra i controller layers e gli host layers troviamo la HCI (Host Controller Interface), l’interfaccia tramite la quale un host comunica con i tre layer inferiori che costituiscono il controller. Vi si accede normalmente tramite il driver del dispositivo Bluetooth. Gli host layers sono:
- L2CAP: Logical Link Control and Adaptation Protocol. Si occupa della creazione e gestione dei canali (channels) per il trasporto dei dati: utilizza a questo scopo il protocollo L2CAP per stabilire una connessione fra gli endpoint dei dispositivi peer. Può opzionalmente fornire funzionalità di recupero errori e di controllo di flusso aggiuntive a quelle fornite dal livello Baseband.
- Application: protocolli SDP, RFCOMM, BNEP, OBEX; profili GAP, PAN, SPP, FTP, ecc.
I profili definiscono le possibili applicazioni di un dispositivo Bluetooth: si avvalgono per il loro funzionamento di uno o più protocolli. Possono dipendere anche da altri profili. Vediamo una breve descrizione dei profili e dei protocolli che risultano più interessanti per i nostri scopi. Tra i profili ricordiamo i seguenti:
- GAP: Generic Access Profile, il profilo di base che tutti i dispositivi Bluetooth devono supportare per permettere l’interoperabilità fra gli stessi. Permette inoltre di interrogare i dispositivi remoti riguardo alle applicazioni (o servizi) che essi supportano.
- SPP: Serial Port Profile. Tale profilo permette di realizzare il cosiddetto cable replacement di connessioni legacy RS-232 cablate. Vedremo che è il profilo supportato praticamente da tutti moduli Bluetooth per sistemi embedded. Le specifiche di
questo profilo prevedono velocità massime di 128 Kbps, ma spesso le implementazioni superano tale limite. Tale profilo sfrutta RFCOMM per emulare la porta seriale (vedi oltre).
- DUN: Dial-Up Networking, è probabilmente il profilo più noto poiché permette di connettersi ad una rete WAN mediante dial-up. Lo scenario più comune è quello di un telefono cellulare Bluetooth usato per connettere un PC ad Internet mediante GPRS/UMTS/HSDPA. È basato sul profilo SPP.
- PAN: Personal Area Networking, permette di creare una rete ad-hoc tra due o più dispositivi Bluetooth, ed anche di ottenere l’accesso ad una rete LAN o WAN mediante un Access Point Bluetooth.
Tra i protocolli del layer inferiore vi sono:
- SDP: Service Discovery Protocol, il protocollo mediante il quale un SDP client può ricevere informazioni dall’SDP server di un dispositivo remoto riguardo i servizi (ad esempio SPP, PAN o altro) che è in grado di fornire.
- OBEX: OBject EXchange, un protocollo di comunicazione client-server che permette lo scambio di oggetti dati tra dispositivi. È usato da diversi profili tra cui FTP (File Transfer Profile) ed OPP (Object Push Profile).
- RFCOMM: Radio Frequency COMMunication. Questo protocollo emula il funzionamento di una porta seriale RS-232 su un canale Bluetooth. È in grado di emulare anche tutti i segnali di controllo RS-232 e crea automaticamente una connessione null-modem quando i dispositivi Bluetooth sono entrambi DTE (ad esempio due PC). È utilizzato da numerosi profili tra cui SPP, DUN, e dal protocollo OBEX.
- BNEP: Bluetooth Network Encapsulation Protocol; permette di incapsulare pacchetti provenienti da protocolli di networking come IPv4 e IPv6. Viene usato dal profilo PAN.
Questa lunga introduzione sulle caratteristiche dello standard Bluetooth è stata necessaria per acquisire una certa padronanza dei concetti necessari per comprendere le caratteristiche e l’uso dei moduli Bluetooth che vedremo nel seguito.
MODULI ADATTATORI BLUETOOTH PER SISTEMI EMBEDDED
Esamineremo ora alcuni moduli adattatori Bluetooth per sistemi embedded: i moduli Parani ESD100 ed ESD200 di Sena Technologies ed il modulo F2M03AC2-SPP di Free2Move. Nella tabella in figura 3 possiamo vedere un raffronto delle caratteristiche dei moduli. Tutti i moduli in questione sono adatti per ottenere il cable replacement di applicazioni scritte per fare uso dell’interfaccia RS-232: implementano infatti il profilo SPP tramite il quale è possibile emulare la porta RS-232 in maniera trasparente per l’applicazione.
Sono inoltre dotati di antenna integrata. Questi adattatori implementano sia i controller layer che parte degli host layer: In particolare sono sempre implementati, tramite un microcontrollore integrato, i layer (ed il protocollo relativo) L2CAP, il protocollo RFCOMM ed il profilo SPP. Verso l’host si collegano tramite una interfaccia UART. Le velocità massime ottenibili si aggirano sui 230 Kbps per un collegamento half-duplex, diminuiscono sui 170 Kbps per un collegamento fullduplex. Nello standard Bluetooth infatti, i collegamenti fullduplex vengono simulati intercalando i pacchetti che vengono trasmessi dal master con quelli trasmessi dallo slave. Come si vede siamo lontani dalla velocità massima di 723 Kbps degli standard Bluetooth 1.x: ciò è dovuto in parte a delle elaborazioni effettuate dallo stack per emulare la connessione RS-232 sul canale RF, in parte alle risorse limitate dei moduli. Comunque le velocità ottenibili sono più che adeguate per gli scopi di cable replacement. Il modulo F2M03AC2-SPP, in più, permette di trasmettere contemporaneamente dati e voce su due canali full-duplex. È dotato di ingressi/uscite analogiche per microfono e speaker, inoltre è presente un’interfaccia digitale PCM bidirezionale: per poter usare tali canali voce però, è richiesto che anche il dispositivo Bluetooth remoto sia un F2M03AC2 (o compatibile). Sono disponibili anche 8 pin di I/O digitali e due analogici. Oltre all’interfaccia UART, possiede anche una interfaccia USB. Rispetto ai moduli Parani, presenta lo svantaggio d’essere più difficile da usare in ambiente di prototipazione dato che si tratta di un dispositivo SMD (è necessario l’uso di un saldatore ad aria calda). I moduli Parani presentano invece un connettore a passo standard da 2.54 mm.
L’APPLICAZIONE D’ESEMPIO
Per l’applicazione d’esempio si è scelto di utilizzare un modulo Parani ESD200: sebbene sia meno dotato del modulo Free2Move, è più semplice da usare e comunque, dato che verrà interfacciato con un microcontrollore, quest’ultimo potrà fornire gli I/O che ci servono. Questo è ciò di cui abbiamo bisogno per la nostra applicazione di cable replacement. Come già detto, il modulo ESD200 si interfaccia all’host tramite UART: il modulo viene configurato e gestito mediante un set di comandi AT esteso. È fornito un insieme di 31 comandi AT suddivisi nelle seguenti categorie:
Reset: reset software o hardware del modulo
- Serial Port: configurazione UART
- Bluetooth: informazioni sulla configurazione, ricerca dispositivi, connessione, gestione della sicurezza
- S-Register: lettura/scrittura di registri contenenti altri parametri di configurazione del modulo
Nella figura 4 sono descritti i comandi AT usati nell’applicazione.
L’hardware dell’applicazione
L’hardware si basa sul microcontrollore PIC18F2550, appartenente alla famiglia di micro ad 8 bit avanzati PIC18. Questi sono dei processori RISC con architettura Harvard modificata: possiedono un set di 75 istruzioni rispetto alle 35 della famiglia PIC16, sono inoltre ottimizzati per l’uso di un compilatore C. Un set esteso di 8 istruzioni aggiuntive può essere usato per ottimizzare ulteriormente l’uso del compilatore. Il PIC18F2550 in particolare possiede 32 KB di memoria Flash (16 K x 16), 2 KB di RAM e 256 B di EEPROM. Comprende un moltiplicatore hardware 8 x 8 bit ed ha una dotazione molto ricca di periferiche, tra cui un USART ed anche una interfaccia USB Full Speed. Può funzionare alla velocità di clock massima di 48 MHz. Nella descrizione dell’hardware che segue facciamo riferimento allo schema elettrico in figura 5.
Il pin 8 (RXD – ingresso dati UART) del modulo Parani ESD200 è collegato al pin 17 che corrisponde al TX dell’USART del PIC, mentre il pin 7 (TXD – uscita dati UART) è collegato al pin 18 (RX) del PIC. I moduli Parani possono essere usati con o senza controllo di flusso hardware: poiché nella nostra applicazione non lo useremo, è necessario porre a massa il pin 5 (CTS - Clear To Send). Il controllo di flusso hardware è consigliato quando si usa un baud rate dell’UART superiore a 38400 baud: volendo è relativamente semplice implementare tale controllo dedicando due pin del PIC18 ai segnali CTS ed RTS (Ready To Send). Il pin 3 (DCD – Bluetooth Connect Detect) dell’ESD200 è collegato al pin 23 (RB2) del PIC per segnalare l’avvenuta connessione del modulo Bluetooth: questo sarà segnalato dall’accensione del LED2. Il LED1 viene usato per segnalare la condizione di ‘Ready’ del modulo, come vedremo quando parleremo del firmware del PIC. Il clock del sistema viene generato tramite il quarzo collegato tra i pin 9 e 10 (OSC1 e OSC2) del PIC. Il PIC è configurato per l’uso di un PLL interno che genererà a partire dai 4 MHz del quarzo il segnale di clock reale del micro a 24 MHz. Per interfacciare il PIC col mondo esterno, useremo due pin di I/O: il pin 21 (RB0) verrà configurato dal firmware come ingresso TTL, mentre il pin 22 (RB1) verrà configurato come uscita. Le uscite del PIC possono sopportare un carico massimo di 25 mA e sono compatibili CMOS/TTL. Volendo, potremo naturalmente utilizzare dei relè o dei fototriac per poter pilotare dei carichi diversi, e usare degli optoisolatori per gli ingressi. Il tutto verrà alimentato tramite una tensione stabilizzata di 3.3 V, con una corrente massima di circa 300 mA.
Il firmware
Il firmware è stato sviluppato tramite l’ambiente di sviluppo MPLAB ed il compilatore C18 di Microchip. La funzione principale main() è rappresentata nel flow chart in figura 6.
In questa funzione vengono innanzi tutto inizializzate le porte di I/O del PIC, quindi, se necessario, viene effettuato il setup del modulo Bluetooth richiamando la funzione BTSetup(). Completato il setup, verrà settato il flag SETUP_DONE nella memoria EEPROM, flag che viene controllato ad ogni accensione del PIC. La funzione BTSetup() configura il modulo Bluetooth tramite i comandi AT descritti nella tabella in figura 4: infatti i moduli Parani sono settati in fabbrica in modo da funzionare con un baud rate di 9600 baud e posti in una modalità di funzionamento di attesa di comandi AT (Mode0). La procedura di configurazione si occupa in particolare di settare l’interfaccia UART a 57600 baud, nessuna parità, e senza controllo di flusso, tramite il comando
AT+UARTCONFIG,57600,N,1
quindi, viene impostato il PIN del dispositivo, ad esempio
AT+BTKEY=”123456”
si abilita allora l’autenticazione con il comando
AT+BTSEC,1,0
Il comando seguente pone il modulo Bluetooth nella modalità di funzionamento Mode3 in cui si predispone ad accettare connessioni da altri dispositivi (è cioè discoverable ed in page scan)
AT+BTMODE,3
Si disabilitano ora i reply da parte del modulo: infatti normalmente quest’ultimo segnala il proprio stato con i messaggi “OK”, “ERROR”, “CONNECT” o “DISCONNECT” che interferirebbero con il funzionamento dell’applicazione di wireless UART
ATS10=0
Infine il comando ATZ effettua un reset software per abilitare la nuova configurazione:
ATZ
Il completatamento della fase di setup viene segnalato dall’accensione del LED1, quindi il processo rimane in attesa di connessione da parte di un altro dispositivo Bluetooth: l’avvenuta connessione viene segnalata dal pin 3 (DCD) del modulo Bluetooth ed all’utente dall’accensione del LED2. Il PIC si predispone allora ad accettare comandi tramite il modulo Bluetooth, utilizzandolo come se fosse un UART in maniera del tutto trasparente: viene innanzitutto abilitata l’USART del PIC settandola a 57600 baud, quindi si entra nel ciclo di polling di ricezione dati. La funzione ProcCommand() si occupa di elaborare il comando ricevuto: se è ‘I’ il PIC risponde inviando il valore letto sul pin di input RB0, se il comando è O0 od O1 il PIC pone il pin di output RB1 al valore 0 od 1 rispettivamente, quindi invia tale valore come conferma. Se il comando ricevuto è errato, viene inviato il carattere ‘?’. Se non ci sono dati in attesa di essere letti nell’USART, il PIC controlla che la connessione Bluetooth sia ancora attiva leggendo il segnale DCD, se non lo è disabilita l’USART ed esce dal ciclo di ricezione dati. Rimane quindi in attesa di una nuova connessione e così via. Il codice della funzione main() è riportato nel listato 1. Si noti che il firmware sviluppato è perfettamente compatibile con i moduli ESD100, mentre i pin hanno una disposizione differente.
void main(void) { unsigned char i = 0; // INDICE BUFFER char UC; // CARATTERE USART char BT_CONNECT = FALSE; char SETUP_DONE = FALSE; /*** INIZIALIZZAZIONI PIC ***/ INTCON2bits.RBPU=0; PORTA = 0; PORTB = 0; PORTC = 0; TRISA = 0B00000000; // PORTA TRISB = 0B00000101; // PORTB TRISC = 0B11000000; // PORTC // SPEGNE LED1 e LED2 LATBbits.LATB3 = 1; // LED1 ‘Ready’ LATBbits.LATB4 = 1; // LED2 ‘Connect’ //*** se e’ necessario effettua il setup // del modulo Bluetooth // legge il flag SETUP_DONE da EEPROM EECON1bits.EEPGD = 0; EEADR = 0; EECON1bits.RD = 1; SETUP_DONE = EEDATA; if (SETUP_DONE!=TRUE) { BTSetup(); EEWrite(TRUE); } LATBbits.LATB3 = 0; // accende LED1 //*** CICLO PRINCIPALE while (1) { //* ATTESA CONNESSIONE BLUETOOTH while (PORTBbits.RB2) { ; } LATBbits.LATB4 = 0; // ACCENDE LED 2 BT_CONNECT = TRUE; // CONNESSO //*** CICLO COMUNICAZIONE DATI //* setup USART per comunicazione BT: //57600,8,N,1 OpenUSART( USART_TX_INT_OFF & USART_RX_INT_OFF & USART_ASYNCH_MODE & USART_EIGHT_BIT & USART_CONT_RX & USART_BRGH_HIGH, 25 ); i = 0; // cancella il buffer memset(buffer,0,BUFFLEN); putrsUSART(“Bluetooth con PIC\r\n”); //* loop ricezione, FINCHE’ IL // MODULO BLUETOOTH E’ CONNESSO while (BT_CONNECT) { // elabora i caratteri ricevuti if (DataRdyUSART()) { switch (UC = ReadUSART()) { case 0x0D: // FINE comando // processa il comando ProcCommand(); putsUSART(buffer); // risposta i = 0; memset(buffer,0,BUFFLEN); break; default: // CARATTERE COMANDO buffer[i++] = UC; // lo copia if (i>BUFFLEN) { // SE buffer pieno i = 0; memset(buffer,0,BUFFLEN); putrsUSART(“\r\n?\r\n”); } break; } } /* CONNECT NON PIU’ ATTIVO? */ if (PORTBbits.RB2) { LATBbits.LATB4 = 1; // SPEGNE LED 2 BT_CONNECT = FALSE; delay(200); } } // fine while(BT_CONNECT) CloseUSART(); // DISABILITA l’USART } // fine while(1) ciclo principale } // fine main()
Listato 1 |
Configurazione del PC ed uso del sistema Bluetooth
Una volta acceso il nostro sistema attendiamo che il setup del modulo Bluetooth sia completato, come segnalato dall’accensione del LED1 ‘Ready’. La prima volta che vorremo usare la nostra applicazione, sarà innanzi tutto necessario configurare il PC: nel seguito facciamo riferimento ad un PC con sistema operativo Windows XP (la configurazione è analoga se usiamo un PDA con Pocket PC o Windows Mobile). Clicchiamo col tasto destro del mouse sull’icona Bluetooth presente sulla barra delle applicazioni e selezioniamo la voce Esplora Risorse di Rete Bluetooth. Dalla schermata relativa clicchiamo sulla voce di menu Bluetooth>Cerca periferiche. Nel giro di qualche secondo comparirà all’interno della finestra l’icona del modulo Bluetooth ESD200 (figura 7a). Facciamo doppio click sull’icona (o clicchiamo sulla voce Rileva servizi): comparirà una icona a forma di connettore seriale relativa al servizio Porta Seriale (figura 7b). È necessario ora effettuare il pairing tra il PC ed il modulo. Ancora doppio click sull’icona del connettore seriale: sulla icona Bluetooth della barra della applicazioni comparirà un fumetto indicante la richiesta di connessione (figura 7c): clicchiamo sul fumetto ed immettiamo il PIN corrispondente a quello memorizzato nel firmware del modulo (nel nostro esempio “123456”). Completata la procedura comparirà una message box che ci indica quale porta COM virtuale è necessario usare per comunicare col modulo Bluetooth (figura 7d). Chiudiamo la connessione cliccando col tasto destro del mouse sull’icona della seriale e selezionando la voce Disconnetti porta seriale Bluetooth. D’ora in poi possiamo comunicare con il modulo direttamente con una qualsiasi applicazione di terminale, ad esempio, lanciamo Hyperterminal (Accessori>Comunicazione>Hyperterminal) e creiamo una nuova connessione: nelle dialog box che seguiranno selezioniamo la porta COM virtuale suddetta, la settiamo a 57600 baud e senza controllo di flusso. Quindi dalla voce di menu File>Proprietà selezioniamo la scheda Impostazioni, clicchiamo su Impostazioni ASCII e spuntiamo la casella Eco dei caratteri digitati localmente. All’uscita da Hyperterminal scegliamo di salvare la sessione. Le volte successive sarà sufficiente lanciare la connessione con Hyperterminal per comunicare col sistema. Vediamo in figura 8 una schermata di Hyperterminal con una sessione di collegamento con il modulo.
Una story molto interessante che mette insieme tante informazioni sulla comunicazione Bluetooth e i vantaggi che ne seguono soprattutto per le applicazioni industriali.