SPI o I2C: que usar para un bus largo

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?

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.

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)

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.

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.

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.

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.

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.

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í.

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 :).

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.