Capitolo 1 - La comunicazione nei sistemi
embedded
1.1 Introduzione
Nel progetto di System-on-a-Chip l’interconnessione delle varie unità funzionali è un compito difficile. Questo è dovuto essenzialmente a due motivi. Per prima cosa, a dispetto di tutti gli sforzi di standardizzazione, non esiste una soluzione generale per le interconnessioni che sia adatta per ogni applicazione; in secondo luogo la comunicazione sta divenendo sempre più un fattore importante per la determinazione delle prestazioni globali del sistema.
Cerchiamo di individuare le proprietà fondamentali delle interconnesioni basate su bus e sulla base di queste confrontare alcuni bus paralleli on-chip con particolare attenzione al bus AMBA e alla sua funzionalità. I bus considerati, oltre l’AMBA, sono il Core Connect, il Core Frame, l’HIBI, il Lotterybus, il Marble, il VCI, il bus PI, il Silicon Backplane e il Wishbone. Il Lotterybus e il VCI non definiscono un bus ma un metodo di arbitraggio e un interfaccia comune per bus rispettivamente.
1.2 La classificazione delle interconnessioni basate su bus
Per classificare i bus considereremo tre caratteristiche principali che sono la struttura, le proprietà di trasferimento e l’arbitraggio. Esse sono rifinite ed elencante nella tavola 1.1.
Hierarchical Bidirectional Uni / Shared / Point to Point Synchronous / /Asynchronous Multiple clock domain Test Structures Hand-shaking Split Transfer Pipelined Transfer Broadcast App. specific 1 or 2 level arbitration Pipelined arbitration Centralized / Distributed arbitration Dynamic Configuration Name
AMBA Yes (-1) Shared Sync N/A Yes Yes (-2) Yes N/A specific App. Yes Centralized N/A Core Connect Yes Uni (-3) Sync N/A Yes Yes N/A Yes N/A 1 level Yes Centralized Yes
Core Frame Yes Uni Point to Point Sync Yes N/A (-4) N/A N/A N/a specific App. Yes Centralized N/A HIBI No Bi Shared Sync Yes No No Yes No No 2 levels Yes Distributed Yes Lotterybus Yes N/A Shared Sync N/A N/A N/A N/A N/A N/A 1 level Yes Centralized Yes Marble N/A Bi Shared Async Yes Yes Yes Yes Yes Yes 1 level Yes Centralized N/A VCI N/A Uni N/A Sync Yes No Yes Yes Yes No specific App. No Centralized N/A PI bus N/A Bi Shared Sync N/A N/A Yes No N/A N/A specific App. N/A Centralized N/A Silicon
Backplane N/A N/A (-5) Sync Yes Yes Yes N/A Yes Yes 2 levels Yes Distributed Yes Wishbone N/A (-6) Shared Sync Yes No Yes N/A No N/A specific App. N/A Centralized N/A
Tab 1.1 confronto di alcuni bus paralleli
Note: (-1) L’APB e l’AHB sono unidirezionali, l’ASB è bidirezionale (-2) L’AHB e l’ASB permettono gli split transfer
(-3) Linee dati condivise, linee di controllo point to point ad anello (-4) Il Palmbus utilizza l’handshake, l’Mbus no
(-5) Linee dati condivise, linee di controllo point to point (-6) Entrambe possibili, unidirezionale raccomandata
1.2.1 La struttura
Nelle strutture gerarchiche due o più bus vengono connessi attraverso dei bridge. A seconda dell’implementazione essi possono trasferire dati indipendentemente finché non ricorrono a risorse residenti sugli altri bus. Un’altra possibilità è che un bus operi come un dispositivo slave. In tale caso il bus slave rimane inattivo finché non viene acceduto. Il bus AMBA adopera questo ultimo metodo per
ridurre i consumi mentre il Core Connect e il Core Frame prevedono due bus indipendenti connessi da un bridge; laddove il Lotterybus definisce un metodo di arbitraggio che non presuppone alcuna topologia di intercomunicazione fissa. Un'altra scelta di progetto è quella di usare linee uni o bidirezionali. Le linee bidirezionali non sprecano risorse di routing ma richiedono buffer tristate il cui uso è generalmente sconsigliato nel progetto di circuiti ASIC, date le difficoltà con la quale se ne effettua il controllo e il test. E’ inoltre da notare che i bus unidirezionali sono generalmente più veloci. La maggior parte dei bus qui considerati sono unidirezionali eccettuato l’HIBI il Marble e il PI. Il bus AMBA e il Wishbone supportano ambedue le possibilità.
La definizione tradizionale di bus prevede che esso utilizzi linee di interconnessione condivise. Questo è vero per tutti eccettuato il Core Frame che adopera un memoria centrale condivisa. In tale bus ogni unità ha una connessione point-to-point con un controllore di memoria. I segnali usati per l’arbitraggio e la decodifica non sono tenuti in conto visto che i segnali di request e grant adoperati normalmente nei sistemi con arbitraggio centralizzato sono comunemente implementati con connessioni point-to-point.
1.2.2 Il clock
Se in tutti i trasferimenti dati si usa il medesimo clock il sistema di comunicazione è sincrono. In tali sistemi è cruciale mantenere la deriva del clock entro limiti accettabili. I sistemi asincroni invece superano tale problema visto che ogni trasferimento dati avviene tramite handshake. E’ da notare che l’handshake è adoperato anche in molti sistemi sincroni per operazioni consistenti in più trasferimenti dati. Un approccio di progettazione localmente sincrono globalmente asincrono permette l’integrazione di blocchi che adoperano frequenze di clock differenti. In tal modo si possono ridurre i consumi cloccando i blocchi alla frequenza più bassa possibile senza curarsi degli altri.
Un fattore chiave nell’utilizzo di una interconnessione è la sua capacità di essere adattata a differenti applicazioni. Sfortunatamente tale proprietà è quasi
impossibile da misurare. Possono essere specificate solamente delle linee guida, come un supporto versatile per la configurazione del bus, sia durante l’uso che durante il progetto. Un supporto per blocchi con clock differenti e diverse larghezza dei dati sono le due proprietà basilari. In più le strutture per i test di fabbricazione stanno divenendo sempre più importanti.
Pressoché tutti i bus su chip usano un clock globale per sincronizzare i trasferimenti. In passato quando i dispositivi erano costituiti da più chip o board i ritardi non potevano essere previsti. Questo si risolveva con protocolli di comunicazione asincroni che permettevano di utilizzare blocchi più lenti insieme ad altri più veloci. Il bus Marble è l’unico di quelli considerati che utilizza un timing asincrono. Tuttavia alcuni bus sincroni permettono ugualmente l’integrazioni di blocchi con domini di clock differenti come mostrato nella tabella 1.1.
1.2.3 I trasferimenti
Per supportare differenti domini di clock si adopera solitamente un handshake fra i master e gli slave. Nei bus asincroni come il Marble, tutti i trasferimenti adoperano l’handshake. Nei sistemi sincroni invece l’handshake non aggiunge ritardi ai trasferimenti dati quando le unità attive sono abbastanza veloci. Quando prendono parte al trasferimento dispositivi più lenti essi possono adoperare segnali di wait per estendere il trasferimento per più cicli di clock. Quasi tutti i bus studiati fanno uso dell’handshake. L’HIBI è l’unico che esplicitamente rifiuta ogni handshake durante i trasferimenti dati.
In operazioni di lettura è molto probabile che lo slave non possa fornire il dato immediatamente. Questa situazione può essere gestita con un handshake ma un sistema più sofisticato è l’utilizzo degli split transfer. In uno split transfer, la lettura è separata in due operazioni e il bus è lasciato libero nel mezzo delle due. Così il bus non è riservato inutilmente per esempio nell’attesa di una risposta dal dispositivo slave.
gli stessi dati a tutti i blocchi. Utilizzando il broadcast i dati sono trasferiti simultaneamente a tutti i blocchi destinati. Tale operazione è supportata dal bus Marble e dal Silicon Backplane. L’HIBI prevede un trasferimento di tipo broadcast per la riconfigurazione dinamica ma non per i dati.
Alcuni bus usano trasferimenti in pipeline per raggiungere frequenze di clock più alte. I trasferimenti in pipeline mandano l’indirizzo durante il primo ciclo di clock, per lasciare abbastanza tempo per la sua decodifica, e i dati durante i cicli successivi. E’ possibile che l’indirizzo del trasferimento successivo sia inviato assieme all’ultimo dato del trasferimento precedente.
1.2.4 L’arbitraggio
Una risorsa condivisa, come un bus o una memoria condivisa, soffre delle contese che avvengono quando più blocchi vogliono accedervi contemporaneamente. L’arbitraggio è il metodo comune per stabilire il master corrente. Tradizionalmente l’arbitraggio è realizzato in maniera centralizzata dove ogni blocco può richiedere ad un arbitro centrale il permesso di accedere alla risorsa condivisa. L’arbitro usa un algoritmo per garantire l’uso della risorsa ad uno dei blocchi richiedenti. Tre dei più adoperati algoritmi sono quello a priorità fissa, il round-robin, e quello a divisione di tempo (TDMA). Nel primo l’arbitro assolve alle richieste dei master secondo una priorità fissa; nel secondo tale priorità varia in continuazione ruotando fra tutti i master, mentre nel terzo ad ogni master è assegnata una determinata finestra temporale.
E’ anche possibile implementare l’arbitraggio in maniera decentralizzata in cui ogni blocco conosce lo stato della risorsa condivisa e può decidere da sé il momento giusto per accedervi. Questo metodo non richiede segnali e risorse dedicate ed è spesso usato per ridurre la latenza nell’arbitraggio ma richiede più hardware dell’altro. Tutti i bus considerati utilizzano un arbitraggio a tempo di esecuzione.
L’arbitraggio può essere in pipeline con i trasferimenti dati. In tal modo, il successivo detentore del bus è determinato in anticipo e può accedere alla risorsa
condivisa senza ritardo da quando essa viene rilasciata. Tuttavia alcune applicazioni richiedono uno o due cicli di clock di attesa quando viene cambiato master.
Non vi sono molte variazioni nei metodi di arbitraggio. Tutti i bus considerati eccettuati il HIBI e il Silicon Backplane fanno uso di un arbitraggio centralizzato. Il bus HIBI e il Silicon Backplane invece usano un arbitraggio ibrido a due livelli distribuito fra i blocchi e senza un arbitro centrale, persino la decodifica degli indirizzi è distribuita fra i vari blocchi.
Normalmente l’algoritmo per un arbitraggio ad un livello è il round-robin o quello a priorità fissa. Il bus AMBA, il Core Frame, il VCI, il Pi e il Wishbone non specificano alcun algoritmo di arbitraggio ma solamente la sua interfaccia. Implementando un nuovo e più complicato algoritmo si può regolare il sistema per meglio adattarlo all’applicazione. Nel Lotterybus il master è scelto probabilisticamente dall’arbitro centrale tramite sequenze pseudo-casuali.
1.2.5 La riconfigurazione
Sebbene la maggior parte della comunicazione di un sistema embedded possa essere stimata a tempo di compilazione la sua mole varia dinamicamente, quindi un arbitraggio statico non può soddisfarne a pieno le esigenze. Perciò è ragionevole rendere possibile configurazioni del sistema a tempo di esecuzione. La configurazione potrà definire le priorità, i parametri del TDMA e il massimo tempo di riserva di una risorsa condivisa. In tal modo la comunicazione può essere regolata per incontrare meglio le richieste correnti dell’applicazione. Tuttavia una riconfigurazione dinamica è alquanto complessa da progettare e richiede più risorse hardware. Dei bus considerati quattro supportano esplicitamente una riconfigurazione dinamica: l’HIBI, il Lotterybus, il Silicon Backplane e il Core Connect.
1.2.6 La misura delle prestazioni
sono trasmessi nell’unità di tempo. Sfortunatamente i valori dichiarati sono spesso valori teorici di picco, estremamente difficili da raggiungere in applicazioni reali. Un altro importante metro è la latenza di un trasferimento, essa misura quanto tempo occorre perché il dato arrivi a destinazione. E’ da notare che anche se la latenza può essere di più cicli di clock si può avere ugualmente un alto troughput grazie al pipeline. In connessioni condivise le contese possono incrementare la latenza, è dunque opportuno misurare sia la latenza media che quella worst case. Comunque le prestazioni dipendono fortemente dal tipo di applicazione, quindi per una buona scelta sul bus da utilizzare è utile condurre dei test specifici sui singoli bus.
Concentriamo ora la nostra attenzione sul bus AMBA.
1.3 Il BUS AMBA
Il protocollo AMBA (Advanced Microcontroller Bus Architecture) definisce uno standard [1] per la comunicazione on-chip parallela e costituisce un efficace strumento per la progettazione di sistemi embedded ad alte prestazioni.
Le specifiche AMBA presentano le seguenti caratteristiche:
• Technology independence. L’AMBA è un protocollo on-chip che è indipendente dalla tecnologia. Le specifiche infatti descrivono il protocollo solo ad un livello di ciclo di clock
• Non forniscono alcuna informazione riguardante le caratteristiche elettriche, che saranno completamente dipendenti dal processo di fabbricazione legato alla tecnologia scelta per il progetto
• Definiscono il comportamento dei vari segnali (timing specification) ad un livello di ciclo di clock. Gli esatti requisiti temporali dipenderanno dal processo tecnologico utilizzato e dalla frequenza delle operazioni. Ciò fornisce al progettista maggiore flessibilità nel gestire gli andamenti temporali dei segnali dei
vari blocchi.
Le specifiche AMBA definiscono tre distinte tipologie di bus:
• Advanced High-performance Bus ( AHB ). È per sistemi ad alte prestazioni, ad alte frequenze. Esso costituisce il bus principale e fornisce un’efficiente connessione tra processori, memorie on-chip e off-chip, e può essere interfacciato con macrocelle periferiche a bassa potenza.
• Advanced System Bus ( ASB ). Anche l'AMBA ASB, come l’AHB, può essere utilizzato come bus principale di sistemi on-chip ed è particolarmente adatto nelle situazioni in cui non sono necessarie le alte prestazioni dell'AMBA AHB. Anch’esso fornisce una connessione efficiente tra processori, memorie ed eventuali macrocelle periferiche a bassa potenza.
• Advanced Peripheral Bus ( APB ). L'AMBA APB è invece un bus adatto a supportare la connessione di periferiche a bassa potenza e può essere interfacciato a uno degli altri due tipi di bus AMBA. È caratterizzato da una ridotta complessità del protocollo, ottimizzato per ottenere il minor consumo di potenza.
Le specifiche AMBA sono rivolte a soddisfare quattro requisiti fondamentali 1. Facilitare lo sviluppo di microcontrollori embedded con una o più CPU o DSP (master multipli).
2. Essere technology-indipendent ed assicurare un’alta riutilizzabilità dei vari blocchi.
3. Incoraggiare un progetto modulare del sistema per migliorare l’indipendenza dei processori.
4. Facilitare la fase di testing.
Un sistema basato sull’AMBA tipicamente è costituito da un bus di sistema principale (AMBA AHB o AMBA ASB), che fornisce una interfaccia high-bandwidth tra gli elementi coinvolti nella maggior parte dei trasferimenti ed al
quale può essere connesso un bridge a minor bandwidth APB, al quale la maggior parte dei dispositivi periferici sono collocati.
H ig h B an d w id th E xtern a l M em o ry In terfa ce H ig h -P erfo m an ce A R M p ro ce sso r H ig h B an d w id th O n -ch ip R A M D M A b u s m as ter B R I D G E U A R T T im er K e yp a d P IO A H B o r A S B A P B
Fig 1.1 tipico sistema basato su bus AMBA
L’AMBA APB agisce quindi come un bus secondario che fornisce l’infrastruttura di comunicazione tra le macrocelle periferiche ed il bus principale.
1.3.1 Il bus AMBA AHB
L’AHB è la nuova generazione di AMBA bus che è indirizzata a soddisfare requisiti di alte prestazioni. Esso presenta le seguenti caratteristiche:
• La possibilità di contenere più di un master. • Gestione dei trasferimenti burst.
• Gestione delle transizioni split.
• Non utilizzo di buffer tristate grazie all'uso di due distinti bus per la lettura e la scrittura dati ( read data bus e write data bus ).
• Funzionamento pipelined della trasmissione degli indirizzi e dei dati.
• Operazione di avvicendamento tra due master nella detenzione del bus in un solo ciclo di clock.
• Le più ampie configurazioni di bus dati (64/128 bit).
Un tipico sistema AMBA AHB tipicamente contiene i seguenti componenti: • AHB MASTER -Un bus master è capace di iniziare operazioni di lettura e scrittura fornendo le informazioni di controllo e di indirizzo. Solo un bus master alla volta può utilizzare il bus. Un sistema AHB può comprendere al massimo sedici master.
• AHB SLAVE - Un bus slave risponde alle operazioni di lettura e scrittura in un certo range di indirizzi. Esso fornisce al bus master che l’ha interrogato l’esito (ad esempio successo, fallimento) dell’operazione richiesta.
• AHB ARBITER - Il bus arbiter assicura che solo un master alla volta possa iniziare un trasferimento di dati. Sebbene il protocollo dell’arbiter sia fissato, qualsiasi algoritmo di arbitraggio può essere implementato, a seconda dei requisiti della particolare applicazione. Un sistema AHB non può comprendere più di un AHB arbiter.
• AHB DECODER - L’AHB decoder serve per decodificare l’indirizzo di ogni trasferimento e per fornire un segnale di selezione allo slave che è coinvolto nel trasferimento. Un singolo decoder è richiesto in tutte le implementazioni AHB. Quindi in generale un sistema AHB presenta i seguenti componenti: uno o più master, uno o più slave, un arbiter e un decoder.
1.3.2 Il bus AMBA ASB
L’ASB è la prima generazione dei sistemi bus AMBA. Esso presenta: • La possibilità di contenere più di un master.
• Gestione dei burst.
• Funzionamento pipelined.
dell’AMBA AHB. Come per l’AMBA AHB, un APB bridge viene visto come uno slave. Sia l’AMBA ASB che l’AMBA AHB sono adeguati come bus principale di un sistema. Comunque l’AHB viene raccomandato per tutti i nuovi progetti non solo perché offre migliori prestazioni, ma anche perché è un protocollo single-clock-edge (rising edge), a differenza dell’ASB che usa entrambi i fronti, di salita e di discesa, del clock.
1.3.3 Il bus AMBA APB
L’APB appare come un bus locale secondario che è incapsulato in un singolo AHB o ASB slave. Dato il suo ridotto numero di pin, circa 40 con dati a 8 bit contro 139 pin e linee dati a 32 bit dell’AHB, e la minor complessità del protocollo esso costituisce un’estensione low power del bus principale (AHB o ASB). Il bridge APB viene visto come uno slave che si preoccupa di far comunicare i blocchi presenti nel bus principale con quelli nell’APB. L’AMBA APB dovrebbe essere utilizzato tutte le volte che si vogliono interfacciare periferiche che sono low bandwidth e che non richiedono le alte prestazioni di un bus pipelined. L’ultima versione (rev 2.0) dell’APB prevede che le transizioni di tutti i segnali siano relative ai soli fronti in salita del clock, come nell’AHB. Questo miglioramento, rispetto alla versione precedente, assicura che le periferiche APB possano essere integrate facilmente in un progetto con i seguenti vantaggi:
• Operazioni ad alta frequenza più facili da ottenere.
• Analisi temporale semplificata dall’uso di un solo fronte di clock .
• Molte librerie ASIC hanno una più ampia selezione di registri che lavorano sul fronte di salita.
• Più facile integrazione nei simulatori cycle-based.
Inoltre ciò rende anche più semplice interfacciare l’APB con il nuovo AHB. Una implementazione AMBA APB contiene un bridge APB, che è necessario per
convertire i trasferimenti AHB o APB in una forma adatta per gli slave presenti dell’APB, ed uno o più slaves. Il bridge fornisce anche un secondo livello di decodifica per generare i segnali di selezione degli slave APB.
1.4 La comunicazione seriale
Alternativamente alla scelta di un bus ad alto parallelismo ed alto bit rate si può prendere in considerazione una comunicazione di tipo seriale. Vi sono diverse ragioni per scegliere un’interfaccia seriale, una delle più comuni è la necessità di interfacciarsi con un PC durante lo sviluppo o l’uso del sistema. Per i sistemi embedded che devono interfacciarsi con un computer general purpose un’interfaccia seriale è spesso più semplice da usare dei bus ISA o PCI. Un beneficio della comunicazione seriale è il ridotto numero di pin: si può comunicare serialmente con appena un pin di ingresso uscita e un pin di massa, in confronto agli otto o più delle comunicazioni parallele; proprio per tale semplicità sono spesso preferite nelle comunicazioni off-chip rispetto ai bus paralleli. Inoltre le più comuni periferiche embedded come convertitori A/D e D/A, LCD, sensori di temperatura e altre supportano l’interfacciamento seriale. Un bus seriale può anche provvedere alle comunicazioni fra processori permettendo loro di dialogare senza l’uso di memoria condivisa e semafori e dei problemi che essi comportano.Tutto questo non significa che non bisogna adoperare bus paralleli; per tutte le operazioni microprogrammate i bus paralleli restano chiaramente i migliori e le periferiche mappate sulla memoria rimangono una tecnica comunemente usata nei sistemi con bus dati e indirizzi.
Vediamo ora alcuni tipi di bus seriali comunemente usati nel progetto di sistemi embedded. Cercheremo poi di confrontarli individuandone, analogamente a prima, le proprietà fondamentali. Essendo tutti questi standard utilizzati prevalentemente per connessioni off-chip essi sono meglio definiti dal punto di vista fisico e per questo meglio dettagliati per quanto riguarda le prestazioni. Focalizzeremo poi l’attenzione sugli standard Spacewire ed SPI quali esempi di interfacciamento seriale.
1.4.1 Esempi di alcune interfacce seriali RS-232
TIA / EIA-232-F (conosciuta come RS-232) è un interfaccia comune che può essere trovata su PC. L’RS-232 è uno standard completo che non include solo le caratteristiche elettriche, ma anche quelle fisiche e meccaniche così come l’hardware di connessione, i piedini di uscita e i nomi dei segnali. L’RSR-232 è un’interfaccia point to point nella quale, cioè, due dispositivi hanno la stessa relazione con ogni altro (al contrario delle interfacce master / slave). Essa è capace su distanze moderate di arrivare fino alla velocità di 20 Kbps. Mentre, anche se non espressamente dichiarato nelle specifiche, può raggiungere la velocità di 115.2 Kbps utilizzando connessioni brevi. La lunghezza tipica dei cavi è di 10 metri ma possono essere usati anche cavi di 60 metri se a bassa capacità. Un bus RS-232 è un bus capace di una comunicazione full-duplex fra una coppia di ricevitori / trasmettitori chiamati data terminal equipement (DTE) e data communication equipement (DCE), ognuno dei quali ha un segnale di trasmissione connesso al segnale ricevente dell’altro. Ovviamente vi è un differenza di pin fra le due parti (per esempio un PC è un DTE mentre una periferica ad esso connessa è un DCE).
Ciascun trasmettitore invia dati variando il potenziale sulla linea. Un potenziale maggiore di 3 V è uno zero logico, mentre un potenziale minore di –3 V è un uno logico. Fra questi due potenziali il valore logico è indefinito. Tipicamente una comunicazione RS-232 consiste in un bit di start, più bit dati, un bit di parità e uno o più bit di stop. Comunque le specifiche ufficiali non impongono nessun protocollo di comunicazione né l’uso dei bit di start o di stop.
Fig. 3.1 Esempio di una tipica comunicazione RS-232
Molti sistemi embedded usano l’interfaccia RS-232 per comunicare con un PC o con le periferiche di un PC come il modem. Altri sistemi usano l’RS-232 così da poter monitorare facilmente il traffico del bus con un protocollo di analisi economico o con un PC equipaggiato con due porte seriali. Praticamente tutti i fornitori di microcontrollori hanno prodotti che includono il supporto hardware per l’RS-232, chiamato Universal Asyncronous Receiver Trasmitters (UARTs). Le UARTs sono spesso pilotate ad interruzione di programma e possono raggiungere la velocità di 115.2 Kbps.
RS-422 e RS-485
La TIA / EIA 422-B (conosciuta come RS-422) e la TIA / EIA 485-A (conosciuta come RS-485) sono interfacce differenziali point to point che possono raggiungere velocità di 10 Mbps e distanze fino a 1200 metri. Essendo bus differenziali usano segnali da 1.5 a 6 V per trasmettere le informazioni (in un bus
bilanciato l’immunità al rumore è superiore rispetto ad un bus non differenziale come l’RS-232).
L’RS-422 ha una comunicazione unidirezionale su una coppia di fili da un trasmettitore a più, fino a 10, ricevitori. Se il dispositivo che riceve i dati vuole rispondere al trasmettitore il progettista dovrà usare un bus separato dedicato fra ogni ricevitore e il trasmettitore; per questa ragione raramente si usa l’RS-422 fra più di due nodi.
Dall’altra parte l’RS-485 offre una comunicazione bidirezionale su una coppia di fili fra più transceiver. Alcuni produttori forniscono transceiver con carichi frazionati così da incrementare il numero dei dispositivi collegabili.
L’RS-422 e l’RS-485 spesso usano lo stesso formato start / dati / stop dell’RS-232. In effetti esistono diversi convertitori fra le tre interfacce. Tuttavia bisogna ricordarsi che, mentre l’RS-232 è full-duplex, l’RS-485 è half-duplex cioè lo scambio dati avviene nelle due direzioni ma non contemporaneamente.
I2C
Il bus Inter-Integrated Circuit (I2C) è un interfaccia sviluppata dalla Philips Semiconductors. Il bus I2C è un bus half-duplex, sincrono e multi-master che necessita solamente di due fili per i segnali: data (SDA) e clock (SCL). Queste linee sono tenute alte da resistori di pull-up e controllate via hardware da driver open-drain, formando un’interfaccia ad and cablato.
L’I2C utilizza un protocollo di comunicazione ad indirizzi che permette al master di comunicare con un singolo slave usando un indirizzo a 7 o 10 bit. Ogni dispositivo ha un indirizzo che è assegnato dalla Philips al produttore. In più esistono alcuni indirizzi ad uso speciale, come un indirizzo di chiamata generale e uno di inizializzazione all’alta velocità.
Durante la comunicazione con i dispositivi slave, il master genera tutti i segnali di clock per la comunicazione verso e dallo slave. Ogni trasmissione comincia con il master che genera una condizione di avvio, una trama di otto bit per i dati, un bit
di avviso, seguito da una condizione di stop. Ogni bit dati viene inviato mentre SCL è basso, eccetto per le condizioni di avvio e di stop. L’avvio viene dato da una transizione alto basso di SDA con SCL alto, mentre lo stop viene dato da una transizione basso alto di SDA con SCL alto.
Fig. 3.2 Esempio di comunicazione I2C
Il bit di avviso è generato dal ricevitore del messaggio portando bassa la linea SDA mentre il master la rilascia; se il master legge il bit di avviso alto considera l’ultima comunicazione non ricevuta e procede appropriatamente, per esempio rinviando i dati.
L’I2C ha un'altra interessante caratteristica chiamata clock stretching, che è usata quando lo slave non è in grado di elaborare i bit e necessita di più tempo. Quando ciò avviene lo slave porta bassa la linea SCL; visto che i segnali sono collegati con un and cablato, quando il master rilascia la linea SCL mentre lo slave sta operando lo stretching del clock, esso si accorge che la linea resta bassa; dopo di ciò il master attende che lo slave elabori i bit e rilasci la linea.
Il bus I2C ha tre velocità: lenta (sotto i 100 Kbps), veloce (400 Kbps) e alta velocità (3.4 Mbps), ognuna compatibile con quelle inferiori. La Philips ha specificato nello standard un modo in cui i segnali dovrebbero lasciare la board. Le distanze di tale bus sono spesso limitate a comunicazioni sulla board; sebbene
alcuni progettisti abbiano usato l’I2C con successo su distanze di oltre 15 metri, in pratica per le comunicazioni fuori dalla board le distanze sono limitate ai 3 metri per velocità moderate.
SPI
Il Serial Peripheral Interface [2] è un bus seriale sincrono sviluppato da Motorola e presente in molti dei suoi microcontrollori. Il bus SPI consiste di quattro segnali: master out slave in (MOSI) , master in slave out (MISO), serial clock (SCK) e slave select (SS_). Come un protocollo multi – master / slave la comunicazione fra il master e lo slave selezionato fruisce delle linee unidirezionali MOSI e MISO per raggiungere velocità di 1 Mbps in modalità full-duplex. I dati sono portati dentro il master e lo slave contemporaneamente basandosi sugli impulsi di SCK forniti dal master.
Oltre alla velocità di 1 Mbps un altro vantaggio dell’SPI è che se si usa un solo dispositivo slave si può tenere sempre bassa la linea SS_ che non ha bisogno di essere pilotata dal master. Uno svantaggio è la richiesta di una linea SS_ per ogni slave. Quindi per piccoli microcontrollori con pochi pin un’interfaccia SPI con più slave può non essere una soluzione realizzabile.
Microwire
La Microwire è un interfaccia sincrona a tre fili sviluppata da National Semiconductor e presentata nella famiglia di processori COP8. Similmente all’SPI, il Microwire è un bus master / slave, con uscita dati del master (SO) e ingresso dati del master (SI), e clock seriale (SK). Questi corrispondono al MOSI, MISO e SCK rispettivamente dell’SPI. E’ presente anche un segnale di chip select simile al SS_ dell’SPI. Il bus Microwire è full-duplex e raggiunge velocità di 625 Kbps o più (capacità permettendo).
I dispositivi Microwire della National hanno protocolli differenti basati sulle loro esigenze. A differenza dello standard SPI, che è basato su dati a 8 bit, lo standard Microwire permette dati di lunghezza variabile, inoltre specifica una modalità di
stringa continua. L’interfaccia Microwire ha gli stessi vantaggi e svantaggi dell’SPI rispetto al numero di slave utilizzati, che richiedono più linee di chip select. Sotto alcune condizioni un dispositivo SPI può lavorare su un bus Microwire e viceversa. Sia l’interfaccia SPI che la Microwire sono generalmente limitate a comunicazioni sulla board e tracce non più lunghe di 15 centimentri, sebbene distanze più lunghe possano essere raggiunte ponendo attenzione alla capacità dei collegamenti e alla velocità della comunicazione.
1-Wire
Il bus 1-Wire della Dallas Semiconductor è un bus asincrono master / slave senza protocolli multi-master. Come il bus I2C, il 1-Wire è un half-duplex, esso utilizza una topologia open-drain su un unico filo bidirezionale. Tuttavia il bus 1-Wire permette anche l’utilizzo della linea dati per trasmettere potenza allo slave, anche se in maniera limitata. Limitato ad una velocità massima di 16 Kbps può raggiungere lunghezze di collegamento di 300 metri utilizzando appropriati resistori di pull-up.
Spacewire
La definizione dello standard Spacewire [3], promosso dall’ESA partendo dallo standard IEEE-1355, si articola su differenti livelli: fisico, di segnale, di carattere, di scambio, di pacchetto, di rete, di recupero errori.
L’interfaccia spacewire è full-duplex e trasmette dati a velocità comprese fra 2 e 400 Mbit/s su cavi della lunghezza massima di 10 m. A livello di segnale la codifica avviene per mezzo di due linee Data e Strobe. Il segnale Data segue il flusso di bit che deve essere trasmesso. Il segnale Strobe cambia stato ogni volta che il segnale Data assume valori consecutivi uguali. Questa codifica consente il recupero del segnale di clock con il quale sono stati trasmessi i dati facendo uno XOR delle linee Data e Strobe
Bit banging
utilizzare i pin di I/O generici. Il controllo software di comunicazioni seriali è spesso chiamato bit baging. Esso richiede che il software conosca il timing di ciascun bit. Fortunatamente per gli sviluppatori di sistemi embedded più di una routine bit banging è disponibile in rete per i bus seriali esistenti e per essere utilizzata su praticamente tutti i microcontrollori.
Name Sync/Async Type Duplex Max devices Max speed (Kbps) Max distance (m) Pin(-1)
RS-232 Async Peer Full 2 20(-2) 10(-3) 2(-4) RS-422 Async multi-drop Half 10(-5) 10000 1200 1(-6) RS-485 Async multi-point Half 32(-5) 10000 1200 2 I2C Sync multi-master Half (-7) 3400 <3 2 SPI Sync multi-master Full (-7) >1000 <3 3+1(-8) Microwire Sync Master/slave Full( (-7) >625 <3 3+1(-8)
1-Wire Async Master/slave Half (-7) 16 300 1
Spacewire Sync Peer Full 2 400000 10 4
Tab 3.1 confronto delle caratteristiche dei bus seriali considerati
Note: (-1) Filo di terra non incluso
(-2) Velocità maggiori disponibili ma non specificate (-3) Dipendente dalla capacità dei fili
(-4) Handshake software, un handshake hardware richiede pin addizionali (-5) Numero dei dispositivi in unità di carico.
(-6) Comunicazione unidirezionale
(-7) Limitazioni basate sulla capacità del bus e la velocità (-8) Pin addizionali richiesti per ogni slave aggiunto
1.5 Lo standard Spacewire
Lo standard SpaceWire è il risultato del lavoro dell’ESA con la collaborazione dell’industria e dell’università. A partire dagli standard IEEE 1395-1995 e ANSI/TIA/EIA–644 è stato realizzato uno standard allo scopo di andare incontro alle necessità di comunicazione tra i diversi dispositivi presenti a bordo delle navette spaziali e dei satelliti fornendo un’infrastruttura unificata per il
collegamento di sensori, unità d’elaborazione, unità di memoria e altri sottosistemi. In linea di principio un sistema di elaborazione sviluppato per uno strumento ottico, può essere utilizzato anche per uno strumento radar, semplicemente sostituendo il sensore ottico con quello radar. In questo modo si riducono i costi dello sviluppo, si migliora l’affidabilità e si aumentano il numero di ricerche scientifiche che possono essere realizzate a parità di budget. Inoltre lo standard SpaceWire facilita l’integrazione e la verifica di sistemi di bordo complessi, supportando il collegamento diretto con apparecchiature EGSE (Elettrical Ground Support Equipment) per la verifica dei sistemi a terra.
1.5.1 Caratteristiche principali dello standard SpaceWire
Lo standard SpaceWire [3] consente collegamenti seriali, bidirezionali, point-to-point, full-duplex, utilizzando 4 fili in ogni direzione, due per i dati e due per lo strobe. Esso specifica più livelli di protocollo:
• Livello Fisico: definisce cavi, connettori e specifiche di compatibilità elettromagnetica.
• Livello di Segnale: definisce la codifica, le tensioni, i margini di rumore e la velocità di trasmissione.
• Livello di Carattere: definisce i caratteri di controllo usati per gestire il flusso dei dati.
• Livello di Scambio: definisce il protocollo per l’inizializzazione della connessione, per il controllo del flusso e il riconoscimento degli errori e la successiva re-inizializzazione.
• Livello di Pacchetto: definisce in che modo il messaggio da trasmettere è diviso in pacchetti.
• Livello di rete (Network): definisce la struttura di reti d’interconnessione costruite utilizzando collegamenti SpaceWire e il modo in cui il messaggio è trasferito dal nodo sorgente al nodo destinatario.
1.5.2 Codifica dei segnali
bit che deve essere trasmesso (valore alto quando deve essere trasmesso 1 e basso quando deve essere trasmesso 0), il segnale Strobe cambia stato ogni volta che il segnale Data assume due valori consecutivi uguali. Questa codifica consente il recupero del segnale di clock con il quale sono stati generati i segnali semplicemente facendo lo xor delle linee Data e Strobe .
Fig 3.3 Codifica Data-Strobe
1.5.3 Caratteri
I caratteri si dividono in carattere dato, carattere controllo e codici di controllo. I caratteri dato sono a 10 bit e comprendono: un bit di parità, un flag dato-controllo posto a 0 e 8 bit di valore, con quello meno significativo trasmesso per primo.
I caratteri e i codici di controllo sono costituiti da un bit di parità, un flag dato-controllo posto a 1 e due bit di codice:
Fig 3.5 Caratteri di controllo
Fig 3.6 Codici di controllo
I caratteri sono raggruppati in due categorie: caratteri di collegamento (link-characters, L-Char) e caratteri normali (normal-(link-characters, N-Char).
I caratteri L-Char sono usati a livello di scambio e non a livello di pacchetto e sono FCT, ESC e i codici di controllo.
Gli N-Char sono invece i caratteri dato e i marcatori di fine pacchetto (EOP e EEP) e sono gli unici ad essere passati dal sistema al quale l’interfaccia SpaceWire è connessa all’interfaccia stessa e viceversa.
1.5.4 Controllo del flusso
Il controllo del flusso utilizza il carattere FCT: quando il trasmettitore di un’interfaccia manda all’altro capo del collegamento un carattere FCT significa
che nel suo buffer di ricezione c’è posto per almeno 8 N-Char. Un trasmettitore non può inviare alcun N-Char finché non riceve almeno un FCT, il numero di FCT ricevuti indica al trasmettitore la quantità di N-Char che è autorizzato a mandare (8 per ogni FCT ricevuto). Ciascuna interfaccia può avere un contatore in cui memorizza il numero di N_Char che si aspetta di ricevere: ogni volta che trasmette un FCT incrementa di 8 il contenuto del contatore e ogni volta che riceve un N-Char lo decrementa di 1. Il valore del contatore però non può superare 56 (7 FCT) anche se il buffer di ricezione ha un numero di locazioni maggiore. Perciò può essere inviato un FCT solo se ci sono almeno 8 locazioni disponibili nel buffer di ricezione e il valore del contatore è inferiore o uguale a 48.
1.6 Lo standard SPI
Concentriamo ora l’attenzione sullo standard SPI. Il serial peripheral interface è uno standard per bus seriali stabilito dalla Motorola [2] e supportato su silicio da svariati produttori. Le interfacce SPI sono disponibili su processori per comunicazioni popolari come l’ MPC8260 e microcontrollori come l’ M68HC11. Esse forniscono un collegamento seriale full-duplex nel quale i segnali portano i dati in ambo le direzioni contemporaneamente.
I dispositivi SPI comunicano usando una relazione di tipo master / slave, nella quale il master inizializza la struttura dati. Quando il master genera il clock di trasmissione e seleziona un dispositivo slave i dati possono essere trasferiti in ognuna od entrambe le direzioni. Infatti, per quanto riguarda l’interfaccia, i dati sono sempre trasferiti in ambo le direzioni; sta poi al master e allo slave sapere se il byte ricevuto ha significato. Così un dispositivo deve scartare il byte ricevuto in uno scambio di sola trasmissione o generarne uno inutile in uno di sola ricezione.
Fig. 3.7 Implementazione bus SPI single master, single slave
Lo standard SPI comprende quattro segnali: il clock (SCLK); l’uscita dati master, ingresso dati slave (MOSI); l’ingresso dati master, uscita dati slave (MISO); la selezione dello slave (SS_ ). La figura 3.7 mostra questi segnali in una configurazione con un solo slave. L’SCLK è generato dal master ed è un ingresso per tutti gli slave. MOSI porta i dati dal master allo slave. MISO porta i dati dallo slave al master. Un dispositivo slave è selezionato quando il master asserisce il suo segnale SS_ di selezione.
Se vi sono più dispositivi slave, il master genera segnali di selezione separati per ognuno. Questa configurazione è mostrata in figura 3.8.
Mentre lo standard SPI non descrive un modo specifico per implementare sistemi multi-master, alcuni dispositivi SPI supportano segnali addizionali che rendono possibile tale implementazione. Tuttavia essendo complicato e normalmente non necessario, non è una pratica seguita spesso dai produttori.
Una coppia di parametri chiamati polarità del clock (CPOL) e fase del clock (CPHA) determinano i fronti del segnale di clock sui quali i dati sono pilotati e campionati. Ognuno di detti parametri ha due stati possibili, quindi si hanno quattro combinazioni ognuna incompatibile con le altre. Se si usano più slave con configurazioni differenti il master dovrà riconfigurarsi ogni volta che ha bisogno di comunicare con uno slave diverso.
Fig. 3.10 Comunicazione SPI con CPHA=1
1.6.1 Il bus SPI a livello più alto
Lo standard SPI non prevede un meccanismo di riconoscimento per confermare la ricezione dei dati. Così, in mancanza di un protocollo di risposta, il master non sa neppure se uno slave è collegato. In più l’SPI non offre nessun controllo di flusso. Se si ha bisogno di un controllo di flusso hardware bisogna realizzarlo esternamente all’SPI.
Lo standard SPI non specifica nessun particolare protocollo di comunicazione master / slave ad alto livello. In alcune applicazioni non è richiesto alcun protocollo del genere e sono scambiati solo dati grezzi, per esempio se ci si interfaccia ad un semplice codec; in altre applicazioni è necessario un protocollo ad alto livello, come un protocollo di comando-risposta. Per questo lo standard lascia la massima libertà; bisogna ricordarsi però che il master dovrà iniziare la trasmissione sia per inviare i propri comandi che per ricevere le risposte dagli slave. Un esempio di un semplice protocollo di comando risposta per una rete di sensori basata su bus SPI è dato in [4].
L’SPI ha migliori prestazioni quando si trasmettono stringhe di dati. La sua capacità di comunicazione duplice e i data rate (che si aggirano fino a alcuni Mega bit per secondo) la rendono, in molti casi, estremamente semplice ed efficiente per applicazioni con un solo master e un solo slave. D’altro canto può essere problematico implementare un bus SPI con più di uno slave, data la mancanza di indirizzi interni; la complessità del bus crescerà linearmente con il numero degli slave.
Lontano dall’essere un’inefficiente porta per byte l’SPI può essere un’elegante soluzione per comunicazioni dalle richieste semplici o per creare protocolli di livello più alto.
