SPI o I2C: que usar para un bus largo

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

Las principales alternativas (que dará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 (¿algunos?) AVR 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 incluya un CRC o equivalente para que pueda determinar si un mensaje se ha recibido correctamente (CAN lo tiene como parte del paquete). Teniendo en cuenta esto, también es útil tener una respuesta de tipo ACK / NACK como parte del protocolo para que se pueda retransmitir un mensaje dañado.

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

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

Para I2C en 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 consultar RS485 para este tipo de problemas. Es un protocolo de bus en serie que se comunica a través de líneas diferenciales, por lo que al usar cables trenzados, las posibilidades de ruido se reducen al mínimo. Se pueden alcanzar distancias muy largas de esta manera. El inconveniente sería que necesitaría un IC codificador RS485 adicional (como un MAX485, no muy caro) en su circuito.

Una ventaja que aún no se ha mencionado de SPI sobre I2C es que todos los cables SPI son unidireccionales y siempre se mueven alto o bajo. 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 de la comunicación asíncrona es que generalmente requiere que ambas partes estén "despiertas", con un reloj estable, para intercambiar datos.

Para un proyecto propio, usé 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 de datos ocasional no sería un gran problema) a 10 Mbps y otros datos a 2,5 Mbps sin dificultad.

Si bien I2C y SPI están diseñados para recorridos de corta distancia (unas pocas pulgadas), ambos pueden utilizarse en recorridos más largos con el cable adecuado y prestando 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 de pull-up. Además, hay buffers I2C dedicados y económicos que son bastante fáciles de usar. Sin embargo, aún tendrá que usar una resistencia de extracción de tamaño adecuado para su red.

He utilizado 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, le recomendaría encarecidamente que busque una solución diferente, "más estándar" (por ejemplo, Ethernet, RS485, CAN, etc.). - Especialmente si planea usar cables para alcanzar la distancia de 6 pies entre los microcontroladores.

Solo un FYI, la interfaz entre el control remoto inalámbrico 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 unos 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 muy utilizado.

Trabajé en un proyecto que involucraba alrededor de 80 nodos basados en AVR en una red en estrella que se comunicaba a través de I2C. Fue un desastre total y no funcionó al final. La obtención de actualizaciones en todos los nodos tomó segundos y una conexión defectuosa se desharía de 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. Desafortunadamente, no sé por qué específicamente I2C fue 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 y impedancia de línea y ver qué tipo de frecuencias (tiempos de subida / caída) puede atravesarlas. 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 serie como EIA-232 o 422. Eso podría significar un chip adicional en ambos extremos, pero se extenderá mucho. Si realmente necesitas ir rápido y lejos, necesitarás algo más (Ethernet, no descartes la radio o el láser :).

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