Svantaggi quando si considera SPI o I2C?

Quali compromessi dovrei prendere in considerazione quando decido di utilizzare un'interfaccia SPI o I2C?

Questa scheda di accelerazione / giroscopio breakout è disponibile in due modelli, uno per ogni interfaccia. Uno dei due sarebbe più facile da integrare in un progetto Arduino?

http://www.sparkfun.com/products/11028

Sommario

• SPI è più veloce.
• I2C è più complesso e non così facile da usare se il microcontrollore non ha un controller I2C.
• I2C richiede solo 2 linee.

I2C è un sistema di bus con dati bidirezionali sulla linea SDA. SPI è una connessione point-to-point con dati in entrata e in uscita su linee separate (MOSI e MISO).

Essenzialmente SPI è costituito da una coppia di registri a scorrimento, in cui si sincronizzano i dati in un registro a scorrimento mentre si sincronizzano i dati dall'altro. Di solito i dati vengono scritti in byte avendo ogni volta 8 impulsi di clock in successione, ma questo non è un requisito SPI. Puoi anche avere una lunghezza delle parole di 16 bit o addirittura 13 bit, se lo desideri. Mentre in I2C la sincronizzazione viene eseguita dalla sequenza di avvio in SPI, viene eseguita da SS andando in alto (SS è attivo in basso). Decidi te stesso dopo quanti impulsi di clock si tratta. Se si usano parole a 13 bit, SS bloccherà l'ultimo clock in bit dopo 13 impulsi di clock.
Poiché i dati bidirezionali si trovano su due linee separate, è facile da interfacciare.

SPI in modalità standard richiede almeno quattro linee: SCLK (serial clock), MOSI (Master Out Slave In), MISO (Master In Slave Out) e SS (Slave Select). In modalità bidirezionale sono necessarie almeno tre righe: SCLK (serial clock), MIMO (Master In Master Out) che è una delle linee MOSI o MISO e SS (Slave Select). Nei sistemi con più di uno slave è necessaria una linea SS per ogni slave, in modo che per slave si abbiano linee in modalità standard e linee in modalità bidirezionale. Se non lo si desidera, in modalità standard è possibile collegare in cascata gli slave collegando il segnale MOSI di uno slave al MISO di quello successivo. Ciò rallenterà la comunicazione poiché è necessario scorrere tutti i dati degli slave.N + 3 N + $N$$N+3$$N+2$

Come afferma Tcrosley, SPI può operare a una frequenza molto più elevata di I2C.

I2C è un po 'più complesso. Dal momento che è un autobus è necessario un modo per indirizzare i dispositivi. La comunicazione inizia con una sequenza di avvio unica: la linea dati (SDA) viene abbassata mentre l'orologio (SCL) è alto, per il resto i dati di comunicazione possono cambiare solo quando l'orologio è basso. Questa sequenza di avvio sincronizza ogni comunicazione.
Poiché la comunicazione include l'indirizzamento, sono necessarie solo due linee per qualsiasi numero di dispositivi (fino a 127).

modifica
È ovvio che la linea di dati è bidirezionale, ma vale la pena notare che questo vale anche per la linea di clock. Gli schiavi possono allungare l'orologio per controllare la velocità del bus. Ciò rende I2C meno conveniente per il cambio di livello o il buffering. (Le linee SPI in modalità standard sono tutte unidirezionali.)

Dopo l'invio di ciascun byte (indirizzo o dati), il destinatario deve confermare la ricezione inserendo un impulso di conferma su SDA. Se il tuo microcontrollore ha un'interfaccia I2C, questo verrà automaticamente curato. Puoi ancora bit-bang se il tuo microcontrollore non lo supporta, ma dovrai cambiare il pin I / O dall'output all'input per ciascun riconoscimento o leggere i dati, a meno che tu non usi un pin I / O per leggere e uno per la scrittura.

A 400kHz I2C standard è molto più lento di SPI. Esistono dispositivi I2C ad alta velocità che funzionano a 1 MHz, ancora molto più lento di SPI a 20 MHz.

(modifica: per essere chiari, molte delle seguenti preoccupazioni hanno a che fare con l'integrità del segnale causata dall'uso scheda-scheda dei dispositivi I2C / SPI, come sottolinea correttamente Olin.)

A meno che tu non abbia vincoli che ti spingano fortemente verso un minor numero di fili (avevamo un progetto con un connettore sigillato ermeticamente che ogni contatto aggiuntivo era piuttosto costoso), evita I2C quando possibile e attacca con SPI.

SPI è abbastanza facile da gestire su base hardware e software. Nell'hardware esistono due linee dati condivise, Master In Slave Out (MISO o SOMI) e Master Out Slave In (MOSI o SIMO), un clock condiviso generato dal master e una selezione di chip per dispositivo. La linea CS si abbassa, il clock scorre e si sposta essenzialmente nei bit di input e sposta i bit di output, fino al termine della transazione, a quel punto la linea CS diventa alta. Quando la loro linea CS è alta, i dispositivi slave non comunicano: ignorano le linee CLK e MOSI e mettono il loro pin MISO in uno stato ad alta impedenza per consentire a qualcun altro di usarlo.

Se si dispone di un microcontrollore che utilizza diversi dispositivi SPI e ha una periferica SPI integrata, inviare l'output CS del microcontrollore a un demultiplexer (ad esempio 74HC138) e controllare le linee degli indirizzi per selezionare il dispositivo tra le transazioni SPI; scrivi le parole in un registro per metterle in coda per l'output e le rileggi dopo che il pin CS è alzato in alto.

Poiché i segnali SPI sono tutti unidirezionali, possono essere bufferizzati, utilizzati attraverso una barriera di isolamento con isolatori digitali e possono essere inviati da scheda a scheda utilizzando driver di linea come LVDS. L'unica cosa di cui devi preoccuparti è il ritardo di propagazione di andata e ritorno, che limiterà la frequenza massima.

I2C è una storia completamente diversa. Sebbene sia molto più semplice dal punto di vista del cablaggio, con solo due fili SCL e SDA, entrambe queste linee sono linee bidirezionali condivise che utilizzano dispositivi a drenaggio aperto con un pullup esterno. Esiste un protocollo per I2C che inizia trasmettendo un indirizzo di dispositivo, in modo che possano essere utilizzati più dispositivi se ognuno ha il proprio indirizzo.

Dal punto di vista hardware, è molto difficile utilizzare I2C in sistemi che presentano rumori significativi. Per bufferizzare o isolare le linee I2C, devi ricorrere a circuiti integrati esotici - sì, esistono, ma non ce ne sono molti: ne abbiamo usato uno su un progetto e ci siamo resi conto che potresti usare un isolatore, ma non puoi usane due in serie - ha usato piccole cadute di tensione per capire da che parte era la parte trainante delle cose, e due cadute in serie erano due.

Le soglie del livello logico di I2C dipendono da Vcc, quindi è necessario fare molta attenzione se si utilizzano dispositivi 3V / 3.3V e 5V nello stesso sistema.

Qualsiasi segnale che utilizza un cavo di più di un piede o due deve preoccuparsi della capacità del cavo. La capacità di 100pf / metro non è fuori dall'ordinario per il cavo multiconduttore. Ciò comporta la necessità di rallentare il bus o utilizzare resistenze di pullup inferiori per essere in grado di gestire correttamente la capacità aggiuntiva e soddisfare i requisiti di tempo di salita.

Supponiamo quindi che tu abbia un sistema che ritieni di aver progettato bene e che tu possa affrontare la maggior parte dei problemi di integrità del segnale e che il rumore sia raro (ma ancora presente). Di cosa ti devi preoccupare?

Ci sono un sacco di condizioni di errore che devi essere preparato per gestire:

• Il dispositivo slave non riconosce un byte particolare. È necessario rilevare questo, arrestare e riavviare la sequenza di comunicazioni. (Con SPI, di solito è possibile rileggere i dati inviati se si desidera assicurarsi che siano stati ricevuti senza errori.)

• Stai leggendo un byte di dati da un dispositivo slave e il dispositivo è "ipnotizzato" a causa del rumore sulla linea dell'orologio: hai inviato gli 8 orologi necessari per leggere quel byte, ma a causa del rumore il dispositivo slave lo pensa ha ricevuto 7 orologi e sta ancora trasmettendo uno 0 sulla linea dati. Se il dispositivo avesse ricevuto l'ottavo clock, avrebbe liberato la linea di dati in modo che il master potesse alzare o abbassare la linea di dati per trasmettere un bit ACK o NACK, oppure il master poteva trasmettere una condizione di arresto (P). Ma lo slave mantiene ancora bassa la linea dati, aspettando invano un altro orologio. Se un master non è disposto a provare altri clock, il bus I2C sarà bloccato in deadlock. Mentre ho usato diversi microcontrollori che gestiscono le normali condizioni ACK / NACK,

• Il caso davvero terribile è quando un master sta scrivendo dati su un dispositivo slave e un altro slave interpreta in modo errato l'indirizzo del dispositivo e pensa che i dati trasmessi siano destinati a questo. Abbiamo avuto dispositivi I2C (espansori I / O) che a volte hanno registri impostati in modo errato a causa di ciò. È quasi impossibile rilevare questo caso ed essere robusto al rumore, è necessario impostare periodicamente tutti i registri, in modo che se si verifica questo errore, almeno verrà risolto dopo un breve periodo di tempo. (SPI non ha mai questo problema - se ti capita di avere un problema tecnico sulla linea CS, non persisterà mai a lungo e non otterrai i dati accidentalmente letti dal dispositivo slave sbagliato.)

Molte di queste condizioni potrebbero essere gestite correttamente nel protocollo in caso di rilevamento di errori (codici CRC), ma pochi dispositivi dispongono di questo.

Trovo che devo creare software complessi nel mio dispositivo master I2C per gestire queste condizioni. A mio avviso, non ne vale la pena a meno che i vincoli sul cablaggio non ci costringano a utilizzare I2C e non SPI.

La scheda breakout per dispositivo su SparkFun è in realtà solo per la versione I2C (MPU-6500). La versione MPU-6000 ha entrambe le interfacce SPI e I2C sullo stesso chip e non vedo che SparkFun abbia una scheda con quel chip. Quindi credo che ti limiti ad usare I2C se vuoi usare quella particolare scheda. Ma avrei raccomandato di usare I2C comunque nella tua situazione per i seguenti motivi.

In generale, scoprirai che il bus I2C è più facile da usare dal punto di vista hardware rispetto al bus SPI. I2C è un bus a 2 fili (SCL / SDA):

SCL – Serial clock.
SDA – Serial data (bidirectional).

SPI è un bus a 4 fili (SCLK / MOSI / MISO / CS):

SCLK– Serial clock.
MOSI – Master-out, Slave-in. Data from the CPU to the peripheral.
MISO – Master-in, Slave out. Data from the peripheral back to the CPU.
CS – Chip select.

È possibile disporre di più dispositivi collegati a un bus I2C. Ogni dispositivo ha il proprio set di indirizzi integrato nel chip. L'indirizzo viene effettivamente trasmesso sul bus come primo byte di ogni comando (insieme a un bit di lettura / scrittura). Questo, insieme ad altri costi generali, richiede l'invio di più bit su un bus I2C rispetto a SPI per la stessa funzionalità.

Diverse classi di dispositivi (memoria, I / O, LCD, ecc.) Hanno intervalli di indirizzi diversi. Alcuni dispositivi, che vengono comunemente utilizzati più di una volta in un sistema (come l'espansore I / O PCF8574), utilizzano una o più linee di indirizzo (AD0-2 per PCF8574) che possono essere collegate in alto o in basso per specificare i bit bassi dell'indirizzo. L'MPU-6500 ha una di queste linee di indirizzo (AD0), quindi due di esse possono essere utilizzate nello stesso sistema.

Puoi anche avere più dispositivi su un bus SPI, ma ogni dispositivo deve avere una propria linea di selezione chip (CS). Pertanto, la descrizione a 4 fili è un termine improprio: si tratta in realtà di un'interfaccia a tre fili + un filo aggiuntivo per dispositivo. Non ho esperienza con la serie di schede Arduino, ma credo che questo renderebbe più difficile l'utilizzo di SPI su Arduino, poiché se aveste bisogno di molte linee di selezione dei chip questo inizierebbe a diventare ingombrante con le assegnazioni dei pin comuni utilizzate dai vari scudi .

Credo che la maggior parte delle schede Arduino funzionino a 5 volt, con alcune più recenti a 3.3v. L'MPU-6500 funziona a 3,3v. Se la tensione "alta" in ingresso minima per un bus I2C su una CPU 5v è 3v o inferiore, è possibile evitare problemi di conversione del livello fornendo semplicemente resistori pullup da 10K a 3,3v sulle linee SCL e SDA, poiché il bus è aperto- collettore. Assicurarsi che eventuali pullup interni a 5 v su una CPU siano disabilitati.

Tuttavia ho controllato il foglio dati per l'ATmega2560 (usando come esempio l'ADK 5v Arduino), e la sua tensione 'alta "in ingresso minima è 0,7 * Vcc, o 3,5v che è maggiore di 3,3 V. Quindi hai bisogno di una sorta di livello attivo conversione La TI PCA9306 , che richiede resistori di pullup su entrambi i lati 5v e 3,3v del chip, costa solo 78 centesimi in singole quantità.

Perché mai scegliere SPI su I2C? Principalmente perché SPI può essere eseguito molto più velocemente - fino a molti 10 di MHz in alcuni casi. I2C è generalmente limitato a 400 KHz. Ma questo non è davvero un problema per l'accelerometro MPU-6050/6000, poiché funziona a 400 KHz per I2C e solo 1 MHz per SPI - non c'è molta differenza.

In generale, SPI è un bus più veloce - la frequenza di clock può essere in un intervallo di MHz. Tuttavia, SPI richiede almeno 3 linee per la comunicazione bidirezionale e una selezione slave aggiuntiva per ciascun dispositivo sul bus.

I2C richiede solo 2 linee, indipendentemente da quanti dispositivi hai (entro certi limiti, ovviamente). La velocità, tuttavia, è nell'intervallo di kHz (100-400kHz è tipico).

La maggior parte dei microcontrollori, al giorno d'oggi, ha il supporto hardware per entrambi i bus, quindi entrambi sono ugualmente semplici da usare.

SPI può essere eseguito molto più velocemente di I2C (alcuni dispositivi SPI superano i 60 MHz; non so se le specifiche I2C "ufficiali" consentano dispositivi oltre 1 MHz). L'implementazione di un dispositivo slave che utilizza uno dei due protocolli richiede il supporto hardware, mentre entrambi consentono una facile implementazione di master "software bit-bang". Con un hardware relativamente minimo, è possibile costruire uno slave conforme a I2C che funzionerà correttamente anche se l'host può decidere arbitrariamente di ignorare il bus fino a 500us alla volta, senza la necessità di cavi di handshaking aggiuntivi. Un'operazione SPI affidabile, tuttavia, anche con il supporto hardware , richiede generalmente che si aggiunga un cavo di handshake, oppure che l'host "manualmente" aggiunga un ritardo dopo ogni byte pari al tempo di risposta nel caso peggiore dello slave.

Se avessi i miei druther, il supporto SPI dei controller conterrebbe alcune semplici funzioni extra per fornire trasferimenti di dati bidirezionali trasparenti a 8 bit tra i controller con capacità di handshaking e wake-up, utilizzando un totale di tre fili unidirezionali (Clock e MOSI [master -out-slave-in] dal master; MISO [master-in-slave-out] dallo slave). In confronto, la comunicazione efficiente e affidabile tra i microcontrollori con porte SPI "stock", quando entrambi i processori potrebbero essere ritardati indipendentemente per periodi di tempo arbitrari, richiede l'uso di molti più fili (Chip-Select, Clock, MISO e MOSI per iniziare con, oltre a una sorta di cavo di riconoscimento dallo slave. Se lo slave potrebbe iniziare in modo asincrono a disporre dei dati da inviare (ad es. perché qualcuno ha premuto un pulsante), è necessario utilizzare un altro cavo come "sveglia"

I2C non fornisce tutte le abilità che il mio SPI "migliorato" avrebbe, ma offre capacità di handshaking integrate che mancano all'SPI e in molte implementazioni può essere kludged per fornire anche il risveglio, anche se il master è un software bit-bang. Per la comunicazione tra processori, raccomanderei quindi fortemente I2C su SPI, tranne quando sono necessarie velocità più elevate di quelle che SPI è in grado di fornire e l'uso di pin extra è accettabile. Per le comunicazioni tra processori in cui è necessario un numero di pin basso, le UART hanno molto da consigliarle.

Questa domanda è stata approfondita nelle eccellenti risposte qui, ma forse c'è un altro punto di vista su I ² C che potrei offrire dal punto di vista di un produttore di chip.

L' interfaccia elettrica dell'I ² C è un open collector . Ora respira e pensa alle implicazioni. Usando I ² C, posso progettare un chip totalmente agnostico rispetto alla tensione operativa del bus. Tutto ciò che devo essere in grado di fare è abbassare la linea SDA se mi fa piacere farlo, e confrontare le tensioni di SCL e SDA con una tensione di soglia riferita a terra, che posso scegliere. E se lascio fuori le normali strutture di protezione high side e le sostituisco con altre strutture, posso creare un chip che può totalmente vivere la propria vita indipendente dal resto del sistema - SCL, SDA non alimentano mai corrente al mio chip e io certamente non alimenterà corrente a quei pin. Ecco perché è un bus così bello per orologi in tempo reale e altre cose a bassa potenza come quella.

Una cosa che non ho visto menzionato nelle altre risposte è che I2C supporta più master sullo stesso bus. Se è necessaria una comunicazione bidirezionale e non si desidera utilizzare un metodo basato sul polling, I2C eseguirà il lavoro.

Su distanze più lunghe, CAN ha le stesse capacità ed è più robusto. Ma CAN è un protocollo asincrono che richiede supporto hardware e un ricetrasmettitore, quindi potrebbe non essere un'opzione in un sistema a basso costo.

Utilizzare il protocollo SPI e scrivere i bit direttamente sul dispositivo ogni volta che l'orologio di sincronizzazione è in aumento. Il circuito logico xnor può essere utilizzato per abbinare l'indirizzo "casalingo" da una memoria per selezionare il dispositivo desiderato come se fosse un dispositivo i2c.

L'i2c sta integrando il circuito autorial all'interno del formato del dispositivo, gli standard ... ecc. Sono complessi e diversi, con una SPI puoi usare una memoria SPI per visualizzare un video sullo schermo, ma non i2c.