SPI o I2C: que usar para un bus largo

36

Estoy contemplando un proyecto que requeriría que varios AVR se comuniquen entre sí a través de un autobús. Estarían separados por hasta 6 pies.

Parece que tanto I2C como SPI pueden permitir que una serie de micros se comuniquen a través de un bus, pero no he visto nada hablando de cuánto tiempo sería. ¿Alguien ha intentado conectar estos protocolos a distancias de varios pies?

edebill
fuente
He pasado el bus I2C a través de un cable en una ocasión. En retrospectiva, debería haber usado CAN o RS-485 en su lugar (tenía microcontroladores en ambos extremos).
Nick Alexeev

Respuestas:

19

Como otros han dicho, SPI e I2C se pueden usar a largas distancias siempre que las resistencias pull-up, las frecuencias de reloj, etc.

Las principales alternativas (que proporcionarán una mejor inmunidad al ruido) son RS485 y CAN . Ambos utilizan líneas diferenciales para minimizar los problemas de ruido y se adaptan mejor a esta longitud de transmisión de datos que I2C o SPI. Sin embargo, no creo que muchos AVR (¿alguno?) Vengan con periféricos CAN integrados, lo que hace que el uso de CAN sea mucho más fácil.

Diría que lo más importante a tener en cuenta al elegir un bus es asegurarse de que el protocolo que utiliza para comunicarse entre dispositivos incluye un CRC o equivalente para que pueda determinar si un mensaje se ha recibido correctamente (CAN lo tiene como parte de el paquete). Teniendo esto en cuenta, también es útil tener una respuesta de tipo ACK / NACK como parte del protocolo para que un mensaje dañado pueda retransmitirse.

DrAl
fuente
Parece que cualquiera de los dos funcionará. Estoy pensando principalmente en estos dos protocolos particulares porque la mayoría de los AVR los admiten de forma nativa, sin agregar componentes adicionales. De lo contrario, RS485 o CAN sería una buena opción.
edebill
Si no está restringido a paquetes de orificio pasante, entonces ST tiene sus microcontroladores STM32 y STM8 rentables y potentes con CAN, NXP tiene una gama de microcontroladores LPC17xx y también hay algunos otros. CAN se está volviendo cada vez más común (y asequible) en muchos microcontroladores.
DrAl
1
De hecho, hay algunos AVR con receptores CAN integrados, pero al igual que los otros proveedores, solo está en un subconjunto limitado de sus chips.
davr
1
Microchip tiene algunos PIC con CAN. microchip.com/wwwproducts/Devices.aspx?dDocName=en010302 . Sin embargo, admito que son un poco "originales" para programar, especialmente en las bibliotecas C18 / C30 de Microchip. En la revisión de código, hemos observado algunos códigos de biblioteca que eran muy difíciles de leer debido a los detalles de la implementación: un búfer de transmisión que se usa como búfer de recepción, nombres de banderas que en realidad son lo contrario de lo que representan. Ciertamente no es algo que recomendaría para alguien nuevo en el desarrollo de microcontroladores.
J. Polfer
2
CAN y RS-485 son realmente manzanas y naranjas. CAN define el protocolo de nivel de bits, así como la capa eléctrica física (PHY). RS-485 es solo una especificación de capa física, no especifica nada sobre el protocolo. Depende completamente de usted encontrar o implementar un protocolo real sobre el PHY RS-485. CAN fue diseñado para entornos de alto ruido, se utiliza principalmente en las industrias automotriz y manufacturera. Su protocolo es un sistema de paso de mensajes bastante complejo y tiene una sobrecarga muy alta (baja velocidad de datos real) pero tiene una alta integridad de datos.
Mark
10

Varios pies no deberían ser problemáticos, solo use cables retorcidos si puede. SPI es mucho más fácil de almacenar (si es necesario) que I2C ya que las señales SPI son unidireccionales, mientras que las señales de I2C están en líneas compartidas.

¿Pueden los microcontroladores AVR manejar los modos esclavo I2C y SPI, así como los modos maestros? (necesitarías ambos)

Jason S
fuente
2
cables retorcidos ?? ¡NUNCA tuerza los datos I2C y las líneas de reloj! Con SPI, esto probablemente no sea un problema, pero nunca torcería las líneas de señal a menos que sea un par equilibrado, en cuyo caso la torsión es una muy buena idea.
Wouter van Ooijen
Nunca digas nunca; Tomaría un acoplamiento capacitivo menor (debido a la torsión) entre datos + reloj cualquier día en lugar de un acoplamiento inductivo menor a electrónica de potencia ruidosa (por no torsión)
Jason S
44
Lo siento, definitivamente no estoy de acuerdo. En el estado 1, las líneas tienen una impedancia bastante alta. Visto que está hecho, visto que falla. La mejor opción es tener líneas de tierra de baja corriente entre o incluso mejor en ambos lados de las líneas I2C.
Wouter van Ooijen
10

Para I2C a largas distancias, es posible que desee buscar algunas soluciones de "repetidor de bus I2C". Tenga en cuenta que cualquier distancia máxima que pueda encontrar para la comunicación I2C o SPI se refiere principalmente a la distancia total del bus y no a la distancia entre dos nodos en un bus.

Es posible que desee examinar RS485 para este tipo de problemas. Es un protocolo de bus serie que se comunica a través de líneas diferenciales, por lo que cuando se usan cables trenzados, las posibilidades de ruido se minimizan. Se pueden alcanzar distancias muy largas de esta manera. La desventaja sería que necesitaría un codificador IC RS485 adicional (como un MAX485, no muy costoso) en su circuito.

bpijls
fuente
RS485 es definitivamente una buena manera de hacerlo.
Scott Murphy
tenga en cuenta que RS485 tiene dos aspectos diferentes a RS232 que son algo independientes: los niveles lógicos diferenciales físicos y el aspecto multimaestro. Puede elegir + elegir estos, hemos utilizado traductores LVDS y RS485 con UART (RS232) para punto a punto sin entrar en las partes multipunto de RS485.
Jason S
2
por cierto RS485 no es un protocolo! define solo la capa física. Dicho esto, ¡definitivamente puedes usar SPI sobre RS485! Sería una buena solución mantener las comunicaciones en modo SPI si fuera necesario (supongo que sí, podría estar conectado a un ADC remoto o similar). Al usar SPI sobre RS485, deberá verificar que las velocidades de rotación del transceptor sean compatibles con las tasas de datos SPI propuestas
smashtastic
8

Una ventaja que aún no se menciona de SPI sobre I2C es que todos los cables SPI son unidireccionales y siempre se conducen hacia arriba o hacia abajo. Esto permite una comunicación mucho más rápida de lo que es posible con I2C, reduce la susceptibilidad al ruido y permite el uso de puertas simples como repetidores. Otra opción útil es la comunicación asíncrona simple (un cable en cada dirección). El único inconveniente que puedo ver en la comunicación asincrónica es que generalmente requiere que ambas partes estén "despiertas", con un reloj estable, para intercambiar datos.

Para un proyecto propio, utilicé un protocolo SPI ligeramente modificado de 3 hilos y encontré los resultados satisfactorios. Envío datos de mapa de bits de visualización (donde la corrupción ocasional de datos no sería gran cosa) a 10 mbps y otros datos a 2.5 mbps sin dificultad.

Super gato
fuente
Esta es una respuesta muy antigua, pero ¿diría a qué distancia estaba enviando su protocolo SPI modificado? (Ese es el punto de la pregunta ...)
Daniel Griscom
@DanielGriscom: aproximadamente 3 pies por lo general, sobre cableado no terriblemente impresionante, pero a veces más largo.
supercat
6

Si bien tanto I2C como SPI están diseñados para lances de corta distancia (algunas pulgadas), ambos se pueden utilizar en lances más largos con el cable adecuado y con atención a la capacitancia general del bus.

Si bien tengo poca experiencia con SPI, I2C no es terriblemente difícil dado que siempre debe calcular el tamaño adecuado para su resistencia pull-up. Además, hay memorias intermedias dedicadas y económicas de I2C que son bastante fáciles de usar. Sin embargo, aún tendrá que usar una resistencia pull-up del tamaño adecuado para su red.

He usado I2C para conectar en red entre dos AVR a una distancia de 8 pies, usando solo resistencias pull-up y cable retorcido de alta calidad y bien blindado.

obturador
fuente
debe tener cuidado con I2C con cables multiconductores, la capacitancia puede hacer que el bus se desacelere significativamente.
Jason S
6

Como muchos han sugerido, I2C y SPI se utilizan mejor para distancias cortas. Si bien es posible implementar una solución con estas interfaces, recomiendo encarecidamente que busque una solución diferente y "más estándar" (por ejemplo, Ethernet, RS485, CAN, etc.). - Especialmente si planea usar cables para alcanzar la distancia de 6 pies entre microcontroladores.

Nate
fuente
6

Solo para su información, la interfaz entre el control remoto inalámbrico de Nintendo Wii y su compañero Nunchuck usa I2C a través de un cable de aproximadamente 3 pies de largo. También hay cables de extensión de 3 pies que extienden la longitud total a aproximadamente 6 pies. No es exactamente lo mismo que su configuración (solo dos dispositivos conectados entre sí), pero es un ejemplo de I2C a través de un cable en un producto de consumo ampliamente utilizado.

tcrosley
fuente
4

Trabajé en un proyecto que involucraba aproximadamente 80 nodos basados ​​en AVR en una red estelar que se comunicaba a través de I2C. Fue un desastre total y al final no funcionó. Obtener actualizaciones para todos los nodos tomó segundos y una conexión defectuosa eliminaría toda la red. La última vez que hablé con el tipo que hizo los nodos, dijo que dejó de usar I2C para proyectos como este. Lamentablemente, no sé por qué específicamente I2C era inadecuado aquí.

terraza
fuente
1
I2C es mucho más lento que SPI ... también podría haber sido en cómo su proyecto gestionó el arbitraje en caso de colisiones ... o la capacitancia pudo haber sido lo suficientemente alta con todos esos nodos que simplemente tuvo que usar una velocidad de reloj lenta.
Jason S
2

Debería ser fácil con esas distancias cortas. Lo que podría hacer es averiguar qué significan esas distancias y su cableado en términos de capacitancia e impedancia de línea y ver qué tipo de frecuencias (tiempos de subida / bajada) puede atravesar. Más allá de cierto punto, es mejor tratarlos como líneas de transmisión. Si se ve mal, podría cambiar a otra línea serial como EIA-232 o 422. Eso podría significar un chip adicional en ambos extremos, pero se extenderá mucho. Si realmente necesita ir rápido y lejos, necesitará algo más (ethernet, no descarte la radio o el láser :).

Tissit
fuente
2

Si puede controlar la velocidad del reloj y no necesita transferencia de datos a alta velocidad, debe intentar reducir la velocidad del reloj. Esto lo hará menos susceptible al ruido.

ajs410
fuente