Transmisión Instantánea, Respuesta Selectiva

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

Mi idea actual es esta: use SPI para comunicarse con todos los esclavos vinculando 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 forma solo tengo 6 pines para transmitir a una velocidad de 10Mbps y recibir datos a 400kbps. ¿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 ser 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 del esclavo al maestro no excederá los 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, alrededor de 1 Mbits a todos a la vez. Hay cierta flexibilidad.

¡Gracias!

Si tiene control total sobre el maestro y los esclavos, probablemente pueda implementar la transmisión I2C y ahorrar en los pines SPI. La transmisión será más lenta que SPI, pero a menos que los datos enviados sean mucho más grandes que los datos leídos, probablemente no tenga un gran efecto en el tiempo general.
La transmisión de datos al esclavo desde el maestro es mucho más grande. A veces, los esclavos no tienen nada que transmitir al maestro, a veces son como 10 bytes. Pero todos deben recibir datos en vivo a aproximadamente 1 Mbits por segundo, pero quiero margen de maniobra, así que apunto a más
DE ACUERDO. Será útil editar la pregunta para aclarar sus requisitos. La cantidad de datos que se envían y reciben, la cantidad máxima real de esclavos, la distancia máxima a un esclavo, etc. (Transmitir 10 Mbps por SPI podría ser complicado si hay más de 10 a 20 esclavos, o si son varios metros). lejos, por ejemplo)
Con un pequeño hardware de nivel de placa, puede tener todos los esclavos controlados por un canal SS, pero todas sus salidas MISO alimentan un multiplexor N: 1 en el MISO del maestro. Luego necesita log2 (N) bits para seleccionar un esclavo para escuchar.
Aclaro algunos de los datos que pediste. ¿Brian es su beneficio de hacer un multiplexor cuando un I2C puede manejar los requisitos para escuchar con 2 pines?
@phivms ¿Cuál es la naturaleza de los dispositivos esclavos (microcontroladores, FPGA o algo cableado)? ¿Es esta una configuración de prueba de producción? ¿Es esta una configuración de campo?
microcontroladores que manejan entradas y muestran salidas. Será una instalación de campo.
¿Cómo estás definiendo "al mismo tiempo"? ¿Es que todos necesitan recibir los mismos datos, que generalmente necesitan recibirlos aproximadamente al mismo tiempo, o está haciendo un sistema síncrono en el que presta atención a las latencias reales entre la entrega a cada esclavo (como proporcionar un reloj compartido)?
¿Beneficio de evitar I2C? Solo simplicidad, una interfaz para tratar en lugar de dos. Si eso no es un problema, su propuesta parece sólida.
al mismo tiempo significa que todos los esclavos están escuchando en el mismo puerto. si el maestro envía un byte, dado que todos los esclavos están escuchando el mismo puerto, procesan los datos al mismo tiempo sin demora para que pasen de uno a otro
25 cargas y 2 metros en I2C significa que tendrá que preocuparse por la fuerza de la unidad de los dispositivos, usar pull-ups fuertes y/o búferes y/o interruptores de bus. Pero debería ser factible si tienes cuidado.

Respuestas (2)

Con 10 esclavos que necesitan recibir 1 Mb/s: diría que está entrando en el área de las cosas que deberían resolverse con un bus de múltiples nodos dedicado, en lugar de improvisar.

En general, sin embargo, la idea de usar SPI (con el almacenamiento en búfer de fan-out adecuado, no se dice que ningún maestro SPI pueda controlar un bus con 10 esclavos a diferentes distancias) para la transmisión, e I²C como canal de retorno es sonido.

De esa manera, sin embargo, se obtiene un backchannel sin interrupciones de baja velocidad y unidireccional de alta velocidad, y eso podría complicarse. Como recomendó Brian Drummond, tener un mux que solo asigne el MISO a un solo esclavo le permitiría usar el modo bidireccional "normal", con TX siendo "transmitido" como un "efecto secundario", y eso simplificaría la lógica del bus inmensamente.

Yo diría que para SPI a estas tasas, 2m es en realidad bastante . Definitivamente funciona, si amortigua y diseña cuidadosamente las pistas y los cables, pero es algo frágil que necesitará muchos ajustes.

Considerándolo todo: 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.

Busque en los autobuses existentes:

  • CAN se parece mucho a 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 la transmisión de datos y, por lo demás, se "siente" un poco como un bus I²C multimaestro. Está comúnmente disponible como integrado en MCU, porque es un bus automotriz. Está muy probado. Creo que su modo más rápido funciona a 1 Mb/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 lento
  • 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 dice de dónde provienen los datos; muchos periféricos SPI de microcontroladores en realidad hacen exactamente ese reenvío con sus búferes RX si no modifica el búfer TX.
    Si un esclavo tiene algo que decir, inserta su propio paquete. Funciona si cronometra su bus SPI más rápido que 1 Mb/s, de modo que haya brechas confiables entre los paquetes de transmisión. La desventaja es: implementación propia -> errores, longitud de segmento limitada y, por supuesto, latencia.
  • Ethernet: necesitará microcontroladores que "hablen" a un PHY (MII, RMII, GMII,...) y PHY de ethernet. En una sola PCB, puede salirse con la suya sin imanes adheridos a estos. El lado positivo es obvio (protocolo bien probado, que incluye transmisión, unidifusión, multidifusión, integridad de hardware, depuración madura y fácil, creación de prototipos con una maldita PC normal con una tarjeta de red normal). Desventaja: costo
  • USB: Maestro y esclavos hablan USB 2 FullSpeed ​​= 12Mb/s. Solo permite punto a punto (hasta donde yo sé), necesitará un concentrador USB IC, pero es una solución muy elegante, fácil de probar y relativamente económica. La desventaja puede ser la complejidad del firmware.
¡Gracias! Solo aclaro que no necesitan cada uno 1Mbps en caso de que eso sea lo que estás pensando, yo también transmitiría todos a la vez a 1Mbps. Estoy buscando microcontroladores PIC de 32 bits para este sistema. ¡Voy a investigar lo que dijiste! ¡Gracias!
Entonces, ¿qué número es un requisito difícil entonces? Porque, si en realidad solo necesitas un par de docenas de kb/s, entonces I²C funcionará razonablemente bien y no tendrás que hacer ningún baile especial.
El envío de datos a los esclavos son requisitos mucho más altos, aunque probablemente pueda ir a menos de 1 Mbps por segundo, pero son algunos cálculos aproximados que no sabré hasta que esté cerca del final.
sí, en serio, si no sabemos que va a ser más bajo, entonces 1 Mb/s es un límite estricto para su diseño. No puedes comer un pastel y aún estar indeciso si quieres comerlo.

¿Funcionaría esta idea...

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

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

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 del esclavo SPI puede requerir hardware adicional y un software más complejo que puede ser difícil de hacer bien.

Soy nuevo en esto, así que he estado investigando mucho sobre el mejor método y sentí que hasta ahora era el mejor que se me había ocurrido. Quería estar seguro de que no había algo que me perdí en el proceso
Probablemente hay docenas de formas de hacerlo, algunas de las cuales pueden ser mejores o peores según sus requisitos exactos. Pero cuanto más compleja sea la solución, más difícil será que funcione correctamente. Un error común es pensar que solo necesitas un autobús que sea lo suficientemente rápido para hacerlo todo. En la práctica, puede haber problemas de latencia que hacen que las interfaces separadas sean mejores (así como más fáciles de depurar).
Transmisión Instantánea, Respuesta Selectiva
RespuestasAquíPolítica de privacidad1y, 0v