STM32 Discovery: Le Comunicazioni Seriali

Nelle prime due puntate abbiamo visto un po’ i concetti elementari legati ai microcontrollori, come ingressi ed uscite ed abbiamo sviluppato un paio di semplici progetti. In questa terza puntata “saliamo” di livello introducendo il concetto di comunicazione seriale che ci permetterà nei nostri progetti futuri di connettere la Discovery al computer ed ai sensori in grado di registrare una grande quantità di dati come ad esempio gli accelerometri. Nello specifico vedremo dapprima le periferiche USART, per poi passare all’I2C ed SPI. In questa 3° Puntata sulle STM32 Discovery (qui la prima e qui la seconda) come anticipato nel teaser vedremo come funzionano le comunicazioni seriale, soffermandoci sulla Usart, sull' I2C e sul SPI. Come sempre concluderemo l'articolo con due semplici progetti pratici realizzando dapprima un misuratore di distanze tramite un sensore ad ultrasuoni e dopo un inclinometro tramite un accelerometro. Ma prima diamo una breve ripassata al concetto di comunicazione seriale.

La Comunicazione Seriale

La comunicazione seriale prende il proprio nome dalla modalità con cui vengono inviate le informazioni, ovvero il dispositivo che trasmette, invia le informazioni al dispositivo che le riceve un bit alla volta in modo sequenziale. Questa strategia di comunicazione nel corso degli anni si è dimostrata più economica e più robusta rispetto alla concorrente parallela, riuscendo pertanto a conquistare la quasi totalità delle comunicazioni digitali ad oggi esistenti. Di contro una tale strategia di comunicazione richiede, rispetto al caso parallelo, una architettura di gestione e controllo di gran lunga più complessa, si pensi ad esempio come una banale perdita di un bit durante una comunicazione potrebbe stravolgere il significato del messaggio finale se non opportunamente gestita dalla comunicazione stessa. Per ovviare ad inconvenienti di questo tipo e per velocizzare il più possibile la trasmissione in funzione della qualità e quantità di dati da inviare, nel corso degli anni sono stati sviluppati circa a decina di standard, diversi per modalità di sincronizzazione, per dimensioni dei pacchetto e per l’interpretazione da dare a quest’ultimo.

In questa sede, tenteremo di spiegare, in modo semplice e veloce, le differenze macroscopiche tra i vari standard, rimandando, ancora una volta, il lettore a testi più specialistici nel caso in cui questi fosse interessato a qualche standard specifico. Partiamo dalle modalità di sincronizzazione; in genere possiamo incontrare tre tipi diversi di comunicazione: sincrona, asincrona e isocrona. 

In una comunicazione sincrona il trasmettitore invia i dati un bit per volta con una determinata frequenza costante, ovvero oltre al canale su cui viaggiano i dati ne esiste un altro tra i due dispositivi sul quale viaggia un segnale di clock. Grazie a quest’ultimo il ricevitore, all’interno del treno di impulsi che riceve dal trasmettitore, sa quando finisce un bit e quando ne inizia un altro . Nel caso asincrono invece non esiste nessun tipo di sincronia tra ricevitore e trasmettitore, quest’ultimo quando è pronto inizia a trasmettere serialmente i bit che vengono letti direttamente dal ricevitore. Il pacchetto inviato contiene sempre un bit di start, che segnala al ricevitore l’inizio della trasmissione, i dati da inviare che nel maggior parte dei casi sono otto e poi può contenere anche un bit di parità che ha lo scopo di verificare qualche eventuale errore nella trasmissione e dei bit di stop che segnalano al ricevitore la fine del pacchetto. Nel caso di invio di grosse quantità di dati, questo tipo di comunicazione risulta meno efficiente rispetto alla sincrona in quanto vengono più volte inviati bit che non contengono informazioni come i bit di start e stop. Infine la modalità isocrona è una modalità ibrida che si ottiene quando si fa comunicare un dispositivo sincrono con un asincrono, ciò può avvenire soltanto sotto determinate condizione per le quali rimandiamo a testi più specialistici.

Partendo da questa differenza macroscopica sui i tempi di sincronizzazione, nel corso degli anni sono stati creati decine di standard che adattano lunghezza e formattazione del pacchetti da trasferire in funzione dell’applicazione specifica, potremmo fare decine di esempi ma in questa sede, come già detto ci occuperemo degli standard più usati quando si vuole far comunicare un dispositivo con un computer o con dei sensori.

USART

USART è l’acronimo di Universal Synchronous-Asynchronous Receiver-Trasmitter, ed è l’evoluzione del vecchio UART che non era capace di gestire le comunicazioni sincrone; nei computer si occupa della gestione della comunicazione tramite l’interfaccia RS-232. Il protocollo generalmente è composto da un bit di start, otto bit dati, un bit di parità e qualche volta può anche contare uno o due bit di stop. La comunicazione avviene tramite due canali dedicati, uno di trasmissione ed uno di ricezione, ovviamente intrecciati tra i due dispositivi: il canale di trasmissione di un dispositivo è connesso al canale di ricezione dell’altro e viceversa. Il canale di trasmissione normalmente si trova al livello logico alto, quando un dispositivo è pronto per trasmettere abbassa il livello sulla linea di trasmissione mandando così il primo bit, ovvero il bit di start. Successivamente il dispositivo invia i dati partendo dal meno significativo, per poi concludere con i bit di parità o di stop. Il bit di parità viene utilizzato per il controllo finale del pacchetto ricevuto e si base sul numero di 1 presenti nel pacchetto, i quali all’interno del pacchetto devono sempre essere in numero pari, così se ad esempio se tra i bit di dati ci sono cinque 1 il bit di parità sarà un altro 1. Per quanto riguarda invece i bit di stop, generalmente si possono avere tre opzioni, ovvero 1, 1,5 o 2 bit di stop, durante l’invio del bit di stop il trasmettitore riporta la linea nello stato di riposo. Il concetto di 1,5 bit, ovviamente non ha senso se non si definisce il concetto di bit in una comunicazione di questo tipo. In una comunicazione seriale un bit viene definito da un tempo, ovvero  stabilita la velocità della comunicazione ad esempio 115200 baud (bit al secondo o bps) un singolo bit durerà 1/115200 secondi, circa 8.68 us pertanto dal momento in cui inizia la comunicazione (nel caso asincrono) ogni 8,68 us si avrà un bit diverso nel pacchetto, in questo caso campionando ogni 8,68 us il ricevitore sarà in grado di distinguere un bit da un altro. In questo contesto 1.5 bit non è altro che un tempo di 8,68*1.5 us durante il quale il trasmettitore mantiene costante il livello sul canale. Le caratteristiche peculiari della comunicazione spesso vengono riassunte tramite una sigla, che indica la velocità, la presenza di bit di parità e di stop, così ad esempio una sigla come 19200n1, indica una comunicazione con una velocità di 19200 baud, nessun bit di parità ed un bit di stop.

Come detto una comunicazione su RS-232 ha due canali, uno per la trasmissione ed uno per la ricezione, nei moderni computer si usano segnali di tipo TTL, ovvero 5V equivalgono ad un 1 logico e 0V ad uno zero. Nel caso di comunicazioni tra dispositivi relativamente vicini questa configurazione lavora bene, tuttavia se le distanze tra i dispositivi iniziano a diventare grandi, questa configurazione potrebbe diventare difficile da gestire, in quanto la resistenze interna dei fili su cui viaggiano i segnali potrebbero dissipare quest’ultimi portando ad esempio al ricevitore una tensione di 2.0V che a quel punto potrebbe essere interpretata come uno zero ma che magari in partenza era 1. Per ovviare a questo problema e creare un tipo di comunicazione robusta alle distanze senza variare la configurazione a due canali, nel corso degli ultimi anni la RS-232 è stata sostituita con la RS-485. Questo nuovo standard risolve il problema delle distanze ragionando in modo differenziale, ovvero i due canali di trasmissione vengono virtualmente sostituiti con due generici canali A e B, nel caso in cui su A c’è una tensione di circa 200 mV maggiore rispetto a B, il ricevitore percepirà un 1, e nel caso contrario uno 0. In questo modo se ad esempio abbiamo 5V sul canale A e 4.8V sul canale B a monte, ipotizzando che i due canali siano costruttivamente uguali e che pertanto dissipano la stessa potenza, anche se il ricevitore ad esempio legge 2 Volt sul canale A e 1,8 sul canale B sarà comunque in grado di interpretare il bit in modo esatto. Oggi nei moderni computer la porta seriale con l’interfaccia RS-232 è sparita  e per utilizzarla bisogna ricorrere a convertitori digitali capaci di riadattare lo standard USB. Quasi tutte le scheda di proto-tipizzazione in giro hanno a bordo questi dispositivi che ci permettono di far comunicare la nostra scheda con un computer, tramite la periferica USART, evitando di impelagarci nella complessità dello standard USB.

Noi in questa sede useremo entrambe le implementazioni, iniziando con una delle sei periferiche USART che le Discovery normalmente montano a bordo (collegandola al computer tramite un convertitore USB-Seriale esterno), e poi invece vedremo come usare tramite il VCP la porta USB OTG della scheda.

I2C

Inter Integrated Circuit, o meglio I2C è un tipo di comunicazione seriale, composta da due canali uno per la trasmissione dei dati SDA e uno per il segnale di sincronizzazione SCL.

Normalmente viene utilizzato per far comunicare due dispositivi secondo una logica master-slave come ad esempio un microcontrollore che funge da master ed un sensore che funge da slave, ovviamente nel caso di più sensori si può passare ad un configurazione master-multislave, a patto che i device o nodi abbiano indirizzi diversi. Infatti, nel protocollo vengono previsti 7 bit di indirizzo, ma dei 128 device collegabili sulla stessa rete 16 sono riservati, quindi in un bus I2C possiamo connettere fino a 112  dispositivi. 

La comunicazione tra due dispositivi è molto semplice, (nella figura 1 viene riportato un piccolo schema) quando un master vuole inviare o ricevere dei dati manda un segnale di start sul canale SDA, successivamente il canale di clock SCL, inizia ad oscillare, ed il master su SDA trasmette i sette bit dell’indirizzo del dispositivo con cui vuole comunicare che vengono letti dallo slave ad ogni fronte di salita o di discesa del clock, dopo i sette bit di indirizzo il master trasmette un ultimo bit che indica allo slave chiamato in causa se il master vuole leggere o scrivere un dato, da lì inizia il vero scambio di dati significativi tra i due, che si concluderà con la trasmissione di un bit di stop da parte del master.

Figura 1: Schema Comunicazione I2C

Come accennato una rete di tipo I2C ammette un solo master per volta, ciò significa che più dispositivi nella stessa rete possono comportarsi da master ed avviare una comunicazione a patto che ad ogni istante nella rete ci sia un solo master. La comunicazione I2C nonostante sia nata un po più lenta rispetto ad altre dello stesso tipo, circa 10Khz, nel corso degli anni con la crescente domanda da parte di hobbysti e professionisti di nuovi sensori si è sviluppata o meglio “velocizzata” arrivando nella versione “Fast Mode” a raggiungere i 400 KHz ovvero 400000 bit al secondo e nella versione “High Speed Mode” i 3.4 MHz. Come detto quando un dispositivo che funge da master vuole iniziare una comunicazione porta al livello logico basso la linea dati, questo passaggio avviene tramite un transistor connesso ad emettitore comune nel caso di un tecnologia bjt o tramite un source comune nel caso di una tecnologia mosfet. Quando il dispositivo finisce di comunicare la tensione sulla base del bjt o sul gate del mosfet ritorna nulla e il transistor va in interdizione a questo punto la tensione sulla linea ritorna alta, tuttavia per essere sicuri che ciò accada è sempre consigliabile utilizzare sia sulla linea dati che sulla linea di clock, che costruttivamente è uguale a quella dati, delle resistenze di pull-up connesse tra la Vdd e la linea, in modo da riportare sempre a livello logico alto la tensione su quest’ultima alla fine della comunicazione. Per il dimensionamento di queste resistenze potremmo aprire un capitolo a parte, in quanto, un corretto valore dipende dalla velocità della comunicazione, della lunghezza della linea etc… Tuttavia noi nei nostri esempi, useremo sempre dei valori standard di qualche KOhm.

Le schede Discovery montano a bordo fino a tre diverse periferiche I2C, che a conti fatti ci permettono di utilizzare fino a 336 dispositivi, a patto che abbiano indirizzi diversi, o nella peggiore della ipotesi fino a 3 dispositivi con lo stesso indirizzo, ma in quel caso credo che l’assenza di un altro dispositivo con lo stesso indirizzo dei primi tre non sarebbe per colpa della Discovery.

SPI

Il termine SPI è l’acronimo di Serial Periphepal Interface e come la comunicazione I2C viene comunemente usata per far comunicare un microcontrollore con più dispositivi o sensori.

Normalmente è composta da quattro fili (figura 2); un clock (SLCK), una linea dati in uscita dal master (MOSI), una linea dati in ingresso al master (MISO) e un canale di abilitazione del disposivo slave (SS). Infatti a differenza del protocollo I2C, qui in generale non esiste un sistema di indirizzamento, ovvero è sempre possibile creare una rete con un master e più slave ma il master per selezionare lo slave con cui vuole comunicare non utilizza un sistema di indirizzi ma piuttosto si occupa di abbassare (o alzare, dipende se si considera il negato o meno) un apposito pin sullo slave, chiamato appunto Slave Select.

Figura 2: Schema Comunicazione SPI

Figura 2: Schema Comunicazione SPI

La comunicazione può avvenire in quattro diversi modi, (figura 3) in funzione del clock e delle linee dati. Quando il master vuole comunicare con un slave, abbassa il livello sul pin "slave select" ed a quel punto porta la linea del clock da bassa ad alta (CPOL = 0) o da alta a bassa (CPOL = 1). Per quanto riguarda invece le linee dati queste possono iniziare un nuovo bit sul fronte di discesa del clock (CPHA = 0) o sul fronte di salita (CPHA = 1). Combinando pertanto queste impostazioni si possono avere fino a quattro diverse configuarazioni di una rete SPI; la modalità da usare è funzione dei device con cui si vuole comunicare e raramente può essere definita univocamente dall’utente. Generalmente la modilità di configuruazione viene indicata sui datasheet dei device mediante un grafico o semplicemente specificando i valori a cui settare CPOL e CPHA.

Figura 3: Modalità di Comunicazione SPI

Figura 3: Modalità di Comunicazione SPI

Uno dei maggiori punti di forza del protocollo SPI, che l’ha reso vincente rispetto a molti altri simili è la velocità di comunicazione che nello standard è di 1MHz. Nel caso, infatti, in cui si vuole comunicare con molti sensori in una rete o in cui si voglia comunicare con sensori che inviano una grande quantità di dati; il fattore velocità in applicazioni real time è fondamentale. Ad esempio nel caso di un modulo IMU (Inertial Measurement Unit) a 10 assi, ovvero un modulo che incorpora al proprio interno un accelerometro a tre assi, un giroscopio a tre assi, un magnetometro a tre assi ed un sensore di pressione o di temperatura avremo (nel caso di misure mappate su 2 byte), ben 20 byte totali da leggere dal sensore. Come accennato l’esigenza di comuinicare una grande quantità d’informazioni in una applicazione real time, ad esempio un modulo IMU usato per la gestione di un quadcopter ci spinge ad utilizzare un protocollo capace di fornirci la giusta velocità di comunicazione, nel caso specifico l’SPI.

Le schede Discovery montano a bordo ben tre periferiche SPI, il che ci permette appunto (nel caso di più sensori) di gestire fino a tre bus contemporaneamente, risparmiando altro prezioso tempo per le nostre applicazioni.

1° Progetto Pratico: Usiamo un Sensore di Distanza

Anche in questa puntata, dopo aver visto brevemente un po’ di hardware, vedremo un  paio di esempi pratici che indubbiamente ci schiariranno le idee su come le STM Discovery gestiscono le periferiche descritte.

Ad esempio in questo primo progetto, vedremo come utilizzare la comunicazione seriale tra la Discovery ed il computer e come gestire un sensore tramite il protocollo I2C. Nello specifico useremo un sensore di distanza ad ultrasuoni, ed una periferica USART interna del microcontrollore, delegando la conversione seriale-usb ad un generico convertitore commerciale. Tornando invece al sensore, prima di mettere le mani sul codice, come sempre spendiamo due parole sul principio fisico di quest’ultimo e sul circuito per il suo controllo. Il principio fisico che sta alla base di un sensore di distanza ad ultrasuoni in linea di massima è lo stesso che sta alla base dei radar o dei sonar, ovvero il sensore è composto da due elementi; un ricevitore ed un emettitore. Quando l’emettitore, invia un’onda con una certa  frequenza (non udibile dall’orecchio umano) il sensore inizia a contare, fino a quando l’onda di partenza non arriva al ricevitore, a quel punto conoscendo la velocità dell’onda nell’aria (spesso si approssima a quella della luce) ed avendo misurato il tempo di volo, si calcola facilmente lo spazio esistente tra il sensore ed il generico corpo su cui è andata a sbattere l’onda prima di tornare indietro,

s = (v * t)/2

Il due presente nella formula è dovuto al fatto che il tempo di volo misura, il tempo necessario all’onda per arrivare all'ostacolo, e tornare indietro al sensore, quindi durante il tempo di volo l’onda percorre due volte lo spazio tra il sensore e l’ostacolo (fig. 4).

Figura 4: Schema di Funzionamento del sensore di Distanza

Figura 4: Funzionamento del sensore di Distanza

Nello specifico nel nostro progetto useremo il sensore SRF10 (fig. 5), questo come detto comunica con il mondo esterno tramite I2C, monta a bordo un microcontrollore [...]

ATTENZIONE: quello che hai appena letto è solo un estratto, l'Articolo Tecnico completo è composto da ben 5567 parole ed è riservato agli ABBONATI. Con l'Abbonamento avrai anche accesso a tutti gli altri Articoli Tecnici che potrai leggere in formato PDF per un anno. ABBONATI ORA, è semplice e sicuro.

Scarica subito una copia gratis

Una risposta

  1. Avatar photo Maurizio 31 Dicembre 2015

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend