A 10 esclavos que necesitan recibir 1Mb / s: yo diría que estás ingresando al área de cosas que deberían resolverse con un bus dedicado de múltiples nodos, en lugar de improvisar.
En general, sin embargo, la idea de utilizar SPI (con el almacenamiento en búfer de salida de salida adecuado, no se dice que ningún maestro SPI pueda conducir un bus con 10 esclavos a diferentes distancias) para la transmisión, y I²C como backchannel es el sonido. p>
De esa manera, sin embargo, obtiene una alta velocidad de una vía, un backchannel sin interrupción de baja velocidad, y eso podría complicarse. Como lo recomendó Brian Drummond, tener un mux que simplemente asigna el MISO a un solo esclavo le permitiría usar el modo bidireccional "normal", con la transmisión de TX como "efecto secundario", y eso simplificaría enormemente la lógica del bus.
Argumentaría que para SPI a estas tasas, 2m es en realidad bastante . Definitivamente funciona, si almacena búferes y diseña cuidadosamente los trazados y los cables, pero es una cosa frágil que necesitará una gran cantidad de ajustes.
En general: creo que podría estar mejor con algo como Ethernet. 10 × 1 Mb / s realmente no suena como si estuvieras conectando arduinos, de todos modos.
Buscar en los autobuses existentes:
- CAN suena mucho como lo que quieres. 2m, alta confiabilidad, mucho tráfico de transmisión, respuestas individuales de datos pequeños. Creo que CAN funciona muy bien para transmitir datos, y por lo demás "se siente" un poco como un bus I²C de varios maestros. Por lo general, está disponible como integrado en MCU, porque es un bus automotriz. Está muy probado. Creo que el modo más rápido se ejecuta a 1Mb / s, por lo que no tienes espacio para la cabeza allí.
- LIN: alternativa más barata a CAN (y básicamente obsoleta porque CAN es barata en estos días): demasiado lenta
- I²C: demasiado lento
- SPI en un anillo de registro de desplazamiento: diseñe su propio protocolo. Todos tus esclavos y tu amo forman un anillo; los datos simplemente se desplazan a través de los esclavos en una dirección en una longitud de paquete fija con un byte de encabezado que indica de dónde provienen los datos; muchos periféricos SPI de microcontroladores realmente hacen exactamente ese reenvío con sus buffers de RX si no modifica el buffer de TX.
Si un esclavo tiene algo que decir, inserta su propio paquete. Funciona si registra su bus SPI más rápido que 1Mb / s, de modo que haya brechas confiables entre los paquetes de transmisión. El inconveniente es: implementación propia - > errores, longitud de segmento limitada y, por supuesto, latencia.
- Ethernet: necesitarán microcontroladores que "hablen" a un PHY (MII, RMII, GMII, ...) y PHY de Ethernet. En un solo PCB, puede escapar sin magnéticos adjuntos a estos. El lado positivo es obvio (protocolo bien probado, que incluye difusión, unicast, multidifusión, integridad del hardware, depuración fácil y madura, creación de prototipos con una PC normal con una tarjeta de red normal). Desventaja: Costo
- USB: el maestro y los esclavos hablan USB 2 FullSpeed = 12Mb / s. Solo permite punto a punto (que yo sepa), necesitará un concentrador IC USB, pero es una solución muy elegante, fácil de probar y relativamente barata. El inconveniente puede ser la complejidad del firmware.