Transmisión instantánea, respuesta selectiva

0

Estoy creando un sistema en el que necesito transferir exactamente los mismos datos a decenas de dispositivos, pero necesito respuestas individuales. También necesito limitar la cantidad de pines necesarios y tener la transmisión lo más rápido posible.

Mi idea actual es esta: usa SPI para comunicarte con todos los esclavos atando a todos los esclavos al mismo canal SS. De esa manera todos los esclavos reciben la misma información al mismo tiempo. Cuando se trata de recibir datos, pediría datos de cada esclavo a través de I2C. De esta manera solo tengo 6 pines para transmitir a una velocidad de 10 Mbps y recibir datos a 400 kbps. ¿Funcionaría esta idea o hay una solución mejor?

Necesito una velocidad de transmisión rápida de maestro a esclavo, ya que los datos deben estar en tiempo real, mientras que los datos de los esclavos pueden ser un poco más lentos, por eso elegí I2C.

¿Pensamientos?

Datos adicionales:

  • La distancia de esclavo a maestro no excederá de 2 metros como máximo. Por lo general, será mucho más corto desde una distancia de varias pulgadas.

  • El conteo de esclavos no se extenderá 25

  • Los datos recibidos del esclavo al maestro variarán. Podría ser de 10 bytes a la vez, o podría ser de 100 bytes a la vez.

  • Los datos transmitidos a los esclavos deben ser rápidos en alrededor de 1Mbits a todos a la vez. Hay cierta flexibilidad.

¡Gracias!

    
pregunta phivms

2 respuestas

2

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.
respondido por el Marcus Müller
2
  

¿Funcionaría esta idea ...

Debería, siempre que se cumplan los requisitos de la interfaz (¿SPI fanout?) y los dispositivos puedan manejar las tasas de datos.

  

... ¿o es una mejor solución?

Posiblemente, pero ¿por qué debería importarte? Lo importante es desarrollar una solución que funcione satisfactoriamente . Una ventaja de su idea es que es simple y fácil de depurar, mientras que una solución "mejor" que, por ejemplo, multiplexa las respuestas esclavas SPI pueden requerir hardware adicional y software más complejo que podría ser difícil de conseguir.

    
respondido por el Bruce Abbott

Lea otras preguntas en las etiquetas