Conversione UART-I2C

La crescente convergenza tra i diversi settori dell’elettronica consumer richiede l’integrazione di periferiche con interfacce di comunicazione diverse. Uart ed I2C sono due dei protocolli di comunicazione più diffusi nelle applicazioni low bit-rate. Scopriamo insieme come connettere i due mondi.

UART (Universal Asynchronous Receiver/Transmitter) è un protocollo di comunicazione seriale asincrono di tipo half-duplex o full-duplex; sebbene piuttosto datato (il primo dispositivo UARTlike era basato su commutatori meccanici rotanti, il primo integrato fu costruito nel 1971 dalla Western Digital) risulta ancora oggi largamente utilizzato soprattutto nelle applicazioni a microcontrollore. Prendendo come riferimento il modello OSI, l’UART implementa una versione piuttosto semplice del data-link layer; come mostrato in figura 1, i pacchetti dati consistono di 1 bit di start che serve come sincronizzazione, 7, 8 o 9 bit dati, 1 bit di parità opzionale ed 1 o 2 bit di stop. Non sono definite procedure per accessi in lettura/scrittura, non è previsto un meccanismo di acknowledge né di arbitraggio. Nelle applicazioni più diffuse,  il physicallayer è definito in accordo agli standard EIA RS-232, RS-422 ed RS-485; più di recente non è raro l’impiego di transceiver Low Voltage Differential Signal. I2C (Inter-Integrated Circuit) è invece uno standard di connessione seriale sincrono di tipo half-duplex introdotto da Philips (ora NXP) nel 1980 come bus di sistema interno e successivamente standardizzato nel 1992. Utilizza due linee bidirezionali open-drain con resistori di pullup (eventualmente di tipo current source nelle applicazioni a più elevato data-rate); la tensione di riferimento è tipicamente 3.3V o 5V. Definisce un protocollo di comunicazione master/slave; è supportato un meccanismo di arbitraggio nelle applicazioni multi-master. Come mostrato in figura 2, la comunicazione inizia con l’invio di 1 bit di start, 7 bit di indirizzo del dispositivo slave selezionato ed 1 bit di direzione lettura/scrittura del trasferimento; in funzione di questo, il master o lo slave inviano quindi i dati.

Figura 1: il protocollo UART.

Figura 1: il protocollo UART.

 

Figura 2: il protocollo I2C (da [2]).

Figura 2: il protocollo I2C (da [2]).

Per ogni byte trasmesso è previsto un bit acknowledge da parte del nodo destinazione. Nel caso in cui il dispositivo  slave selezionato  supporti un proprio spazio di indirizzamento, negli accessi in scrittura il  primo dato configura  il puntatore in memoria interno (subaddress); in figura 2 è mostrata la sequenza di operazioni per accedere in lettura ad una particolare locazione. Informazioni più dettagliate sul protocollo I2C sono disponibili accedendo direttamente allo standard, scaricabile gratuitamente dal sito di NXP [1]. In base a quanto discusso finora, quindi, la realizzazione di un bridge UART-I2C richiede:

➤ la conversione di livello fisico tra i due standard;

➤ l’implementazione  di un protocollo di più

alto livello su link UART che definisca almeno le procedure elementari per gli accessi in lettura/scrittura in memoria come sulla rete I2C. I successivi  paragrafi discutono un semplice esempio di tale protocollo ed alcune delle soluzioni hardware a basso costo disponibili per l’implementazione del bridge.

Semplici  soluzioni per l’hardware

Il primo punto nella realizzazione del bridge, come appena evidenziato, è la selezione del convertitore per i  livelli fisici. L’interfaccia  I2C richiede due porte opendrain che sono già tipicamente integrate nei chipset utilizzati come bridge. Per l’intefaccia UART, invece, transceiver dedicati sono resi disponibili da Analog Devices, National, Maxim/Dallas Semiconductor, Texas Instrument; molti dei dispositivi sono facilmente reperibili come campionatura direttamente dalla casa madre o acquistabili attraverso i distributori come RS e Farnell.  Il costo da catalogo, anche per singoli pezzi e per le versioni che assicurano maggiori prestazioni, è dell’ordine di qualche euro. Per quanto concerne la realizzazione vera e propria del bridge si possono immaginare diverse soluzioni. Una proposta sicuramente interessante nelle applicazioni ad elevato livello di integrazione sono i chipset SC18IM700 (figura 3) e SC16IS740 di NXP.

Figura 3: un dispositivo SC18IM700.

Figura 3: un dispositivo SC18IM700.

Il primo integra un’interfaccia I2C master controllabile da remoto mediante porta UART in base ad un protocollo specifico; supporta baud-rate programmabile fino a 400 kbit/s, ha una modalità sleep-mode ed è compatibile con applicazioni multimaster. I dispositivi SC16IS740 sono, invece, bridge I2C slave / UART; supportano baudrate fino a 5 Mbps e controllo di flusso in hardware mediante i segnali RTS/CTS. Sono compatibili, dal punto di vista del software di gestione, con i dispositivi 16C540. Entrambi i chipset sono disponibili in package TSSOP16 e sono caratterizzati da bassa dissipazione di potenza, aspetti che li rendono quindi ideali, ad esempio, per applicazioni portatili alimentate a batteria. In alternativa alla soluzione NXP, una semplice architettura basata su microcontrollore è presentata nell’Application Note AN-206 “Using a PC’s RS232 Serial Port to comunicate with 2-wire devices” [2] di Maxim/Dallas. Tutti i microcontrollori, infatti, integrano già un’interfaccia UART; alcuni includono anche il controller I2C master/slave e, quand’anche questo non sia disponibile, possono emularlo in software utilizzando due pin di I/O del dispositivo. E’ sufficiente quindi scrivere un applicativo software di più alto livello per la gestione del protocollo di comunicazione su UART. In rete sono facilmente reperibili versioni in C delle routine che implementano interfacce I2C master/slave. Rispetto alla soluzione integrata proposta da NXP, l’utilizzo di microcontrollore consente una maggiore flessibilità dal punto di vista delle prestazione oltre alla possibilità di integrare funzionalità aggiuntive sebbene comporti tipicamente un costo maggiore in termini di dissipazione di potenza e ingombri. Un’altra alternativa alle soluzioni sopra proposte consiste nell’utilizzo di un dispositivo logico programmabile a basso consumo - come ad esempio  i componenti della famiglia IGLOO di Actel - che integri, oltre alla logica di controllo hard-wired, i controller UART ed I2C; in questo caso si è in grado di ottenere elevate prestazioni.

Un semplice protocollo per il bridge

Nell’Application Note AN-206 di Maxim sopra citata, è descritta un semplice protocollo di comunicazione su link UART per la realizzazione di un bridge UART-I2C con funzionalità di tipo master sul bus I2C. Il  protocollo prevede l’invio di sequenze di due caratteri che definiscono rispettivamente l’istruzione e l’operando (eventualmente ignorato qualora non sia richiesto) secondo quando riportato nella tabella 1.

Tabella 1: un generico protocollo per bridge UART-I2C master

Tabella 1: un generico protocollo per bridge UART-I2C master

Un accesso in scrittura,ad esempio, di 0x23 all’indirizzo 0x40 sarebbe codificato dal comando seguente inviato dall’host al bridge (supponendo che ogni comando sia eseguito correttamente): 0xA0 - 0x00 - 0xA1 - 0x40 - 0xA1 - 0x23 - 0xA3 - 0x00.
Il bridge ritorna in risposta verso l’host un carattere di acknowledge (corrispondente allo stato dell’operazione eseguita sul bus I2C) e, nel caso di accessi in lettura, il dato. Più semplice è il protocollo supportato dai dispositivi NXP. In questo caso è previsto un meccanismo di acknowledge solo dell’intero messaggio; la tabella 2 elenca  i comandi previsti dal protocollo.

Tabella 2: il protocollo dell’ SC18IM700

Tabella 2: il protocollo dell’ SC18IM700

Il  comando su UART inizia con un carattere S seguito dall’indirizzo  della periferica I2C slave (utilizzando come nel caso del protocollo I2C il bit meno significativo per segnalare il  verso del trasferimento), dal numero di byte che seguono nel pacchetto, dai dati utente nel caso di accessi in scrittura e dal carattere di STOP (o repeated START).

 

 

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend