SPI o I2C: quale utilizzare per un bus longish

Sto contemplando un progetto che richiederebbe diversi AVR che parlano tra loro su un autobus. Sarebbero separati da ben 6 piedi.

Sembra che sia I2C che SPI possano far comunicare una serie di micro su un bus, ma non ho visto nulla parlare di quanto sarebbe lungo. Qualcuno ha provato a collegare questi protocolli su distanze di diversi piedi?

Come altri hanno già detto, SPI e I2C possono essere utilizzati su lunghe distanze purché i resistori di pull-up, le frequenze di clock e così via.

Le principali alternative (che offriranno una migliore immunità al rumore) sono RS485 e CAN . Entrambi utilizzano linee differenziali per ridurre al minimo i problemi di rumore e sono più adatti a questa lunghezza di trasmissione dei dati rispetto a I2C o SPI. Tuttavia, non credo che molti (qualsiasi?) AVR siano dotati di periferiche CAN integrate, che rendono l'utilizzo CAN molto più semplice.

Direi che la cosa più importante da considerare quando si sceglie un bus è assicurarsi che il protocollo utilizzato per comunicare tra dispositivi includa un CRC o equivalente in modo da poter determinare se un messaggio è stato ricevuto correttamente (CAN ha questo come parte di il pacchetto). Considerando questo, è anche utile avere una risposta di tipo ACK / NACK come parte del protocollo in modo che un messaggio corrotto possa essere ritrasmesso.

Diversi piedi non dovrebbero essere problematici, basta usare fili intrecciati se puoi. SPI è molto più facile da bufferizzare (se necessario) rispetto a I2C poiché i segnali SPI sono tutti unidirezionali, mentre i segnali I2C sono su linee condivise.

i microcontrollori AVR sono in grado di gestire le modalità slave I2C e SPI e le modalità master? (avresti bisogno di entrambi)

Per I2C su lunghe distanze potresti voler cercare alcune soluzioni "I2C bus repeater". Tenere presente che qualsiasi distanza massima che si potrebbe trovare per la comunicazione I2C o SPI si riferisce principalmente alla distanza totale del bus e non alla distanza tra due nodi in un bus.

Potresti voler esaminare RS485 per questo tipo di problemi. È un protocollo di bus seriale che comunica su linee differenziali, quindi quando si usano fili intrecciati, le probabilità di rumore sono ridotte al minimo. In questo modo è possibile raggiungere distanze molto lunghe. Lo svantaggio sarebbe che avresti bisogno di un ulteriore encoder RS485 (come un MAX485, non molto costoso) nel tuo circuito.

Un vantaggio non ancora menzionato di SPI su I2C è che tutti i fili SPI sono unidirezionali e sono sempre guidati in alto o in basso. Ciò consente una comunicazione molto più veloce di quanto sia possibile con I2C, riduce la suscettibilità al rumore e consente l'utilizzo di semplici cancelli come ripetitori. Un'altra opzione utile è la semplice comunicazione asincrona (un filo per direzione). L'unico aspetto negativo che posso vedere per la comunicazione asincrona è che generalmente richiede che entrambe le parti siano "svegli", con un orologio stabile, per scambiare dati.

Per un mio progetto, ho usato un protocollo SPI leggermente modificato a 3 fili e ho trovato i risultati soddisfacenti. Mando i dati di visualizzazione bitmap (dove il danneggiamento occasionale dei dati non sarebbe un grosso problema) a 10 Mbps e altri dati a 2,5 Mbps senza difficoltà.

Mentre entrambi I2C e SPI sono progettati per i viaggi a breve distanza (pochi pollici), entrambi possono essere utilizzati su percorsi più lunghi con cavo adeguato e attenzione alla capacità complessiva del bus.

Mentre ho poca esperienza con SPI, I2C non è tremendamente difficile dato che devi sempre calcolare la dimensione corretta per il tuo resistore pull-up. Inoltre, ci sono buffer I2C dedicati ed economici che sono abbastanza facili da usare. Tuttavia, dovrai comunque utilizzare un resistore pull-up di dimensioni adeguate per la tua rete.

Ho usato I2C per collegarmi in rete tra due AVR a una distanza di 8 piedi, usando solo resistori pull-up e un cavo a spirale schermato di alta qualità.

Come molti hanno suggerito, I2C e SPI sono meglio utilizzati per brevi distanze. Sebbene sia possibile implementare una soluzione con queste interfacce, ti consiglio caldamente di cercare una soluzione "più standard" diversa (ad es. Ethernet, RS485, CAN, ecc.). - Soprattutto se si prevede di utilizzare cavi per raggiungere la distanza di 6 piedi tra i microcontrollori.

Solo un FYI, l'interfaccia tra il telecomando wireless Nintendo Wii e il suo compagno Nunchuck utilizza I2C su un cavo lungo circa 3 piedi. Ci sono anche cavi di prolunga da 3 piedi che estendono la lunghezza totale a circa 6 piedi. Non è esattamente uguale all'impostazione (solo due dispositivi collegati insieme), ma è un esempio di I2C su un cavo in un prodotto di largo consumo.

Ho lavorato su un progetto che coinvolge circa 80 nodi basati su AVR in una rete a stella che comunica su I2C. Era un disastro totale e alla fine non ha funzionato. Ottenere aggiornamenti su tutti i nodi ha richiesto pochi secondi e una connessione difettosa avrebbe eliminato l'intera rete. L'ultima volta che ho parlato con il ragazzo che ha creato i nodi, ha detto che ha smesso di usare I2C per progetti come questo. Sfortunatamente non so perché specificamente I2C fosse inadeguato qui.

Dovrebbe essere facile con quelle brevi distanze. Quello che potresti fare è capire cosa significano quelle distanze e il tuo cablaggio in termini di capacità e impedenza di linea e vedere che tipo di frequenze (tempi di salita / discesa) puoi attraversarle. Oltre un certo punto, è meglio trattarli come linee di trasmissione. Se sembra male, potresti effettivamente passare ad un'altra linea seriale come EIA-232 o 422. Ciò potrebbe significare un chip aggiuntivo su entrambe le estremità ma si estenderà lontano. Se hai davvero bisogno di andare veloce e lontano, avrai bisogno di qualcosa di più (Ethernet, non contare la radio o il laser :).

Se riesci a controllare la velocità del clock e non hai bisogno del trasferimento di dati ad alta velocità, dovresti provare a rallentare il clock. Ciò lo renderà meno suscettibile al rumore.