Elección del mejor bus y protocolo para ~128 clientes por cable

Estoy listo para diseñar un sistema con ~ 128 MCU que se comunican con un maestro de MCU. La comunicación será bidireccional. Los datos serán principalmente lecturas de sensores, pero planeo usar el bus también como método de comunicación para que el gestor de arranque personalizado reprograme el cliente si es necesario. La distancia entre los clientes será de ~10-15 cm (~3,90-5,90 pulgadas). Las MCU se comunicarán a través de cables.

En este momento estoy investigando qué bus y qué protocolo se debe usar con tales requisitos. Mi primer pensamiento fue I2C con direccionamiento de 10 bits, pero me temo que la cantidad de clientes excedería la capacidad máxima del bus I2C.

  1. ¿Qué bus y qué protocolo sería adecuado para este tipo de sistema?
  2. Si la respuesta es I2C, ¿cuál es el método para asegurarse de que los parámetros del bus coincidan con las especificaciones? (He oído hablar de los búferes I2C, ¿ayudarían?)
Con 128 cosas en un autobús, cualquiera que se quede corto o solo hable matará el autobús, ¿cuál será su confiabilidad? En una malla de 12x12, cada MCU necesitaría 2 transceptores I2C, uno para norte/sur y otro para este/oeste. Solo 12 nodos por bus. Cualquier mensaje aleatorio de MCU a MCU necesitará 2 saltos, pero podría realizarse de dos maneras, EW primero o NS primero (o ambas), por lo que cualquier falla de MCU se restringe a esa MCU. Se puede tener una redundancia inferior a la total implementando solo algunos de los buses en una dirección, o incluso solo uno en una dirección (capacidad más baja y efecto de falla limitado)
¿Cuántos datos y con qué frecuencia ?
Cada cliente enviaría ~4 bytes de datos. La restricción de frecuencia de agrupación no es un requisito difícil, pero estaba pensando en leer los datos de todos los clientes cada 500 ms.

Respuestas (3)

¿Situación maestro-esclavo, donde el maestro consulta a los esclavos uno a la vez, y ambos pueden estar transmitiendo al mismo tiempo?

Yo iría con RS485, dúplex completo para la velocidad más rápida, dúplex medio si el maestro habla, el esclavo responde mientras el maestro escucha (de la misma manera que funciona el USB). Resistencia de terminación en ambos extremos de la cadena de cableado, cabos cortos de la cadena de cableado a cada esclavo. Maxim-ic.com tiene algunos buenos artículos a los que publiqué enlaces en el pasado.

Si desea una solución simple y existente, puede optar por Onewire . Está hecho para cientos de dispositivos y cargas de bus elevadas, por lo que no necesita búferes. El principal inconveniente es la baja velocidad debido a eso.

Solo tiene un cable de datos, por lo que la sincronización puede ser otra complicación. Varias implementaciones de clientes para µCs están disponibles.

Pero tenga en cuenta los inconvenientes de un solo autobús:

  • es probable que un solo autobús falle miserablemente y ¿cómo localizar al culpable?
  • actualizar el software a través de un bus lento será una molestia con 128 nodos.

Para un sistema tan abarrotado, debe organizarlos como grupos. Cada grupo es una subred y solo uno de los MCU del grupo tiene la función de ser oyente y altavoz para el exterior y gobernante para el interior. Estos grupos forman los objetivos que el maestro selecciona primero y luego la dirección del elemento de la subred o toda la información que tiene el grupo.

Entonces, la ventaja es que ahora tiene la libertad de implementar diferentes topologías para la red principal y los elementos del grupo para una comunicación más rápida y confiable.

Elección del mejor bus y protocolo para ~128 clientes por cable
RespuestasAquíPolítica de privacidad1y, 0v