Comunicaciones en serie a través de un cable de 3 m, compartido con USB

3

Estoy diseñando un sistema que necesita realizar comunicaciones serie a través de un cable USB estándar, así como un USB normal (pero no al mismo tiempo). En otras palabras, cuando se conecta a una PC, aparecerá como un dispositivo USB y cuando se conecte a un sistema integrado, utilizará un protocolo de comunicaciones serie más simple. El lado del USB es solo de velocidad máxima (12Mb / seg), y las comunicaciones serie solo necesitan ser de 100 Kb / seg, aunque 1Mb / seg sería bueno.

El dispositivo independiente utilizará un microcontrolador para comunicaciones. Tanto el dispositivo como el sistema integrado estarán basados en microcontroladores, probablemente Atmel XMEGA. Una opción sería instalar un dispositivo compatible con USB OTG / host, pero quiero evitar esta complejidad, el costo y la selección limitada de microcontroladores.

Los micros XMEGA tienen periféricos UART y SPI en los mismos pines que USB D + / D-. También podría encaminar I2C desde otros dos pines hasta ellos, y no creo que dañe la calidad de la señal. Dado que el cable USB solo tiene dos líneas, si utilizo SPI sería unidireccional, lo que podría manejar. Sin embargo, I2C bidireccional o 3.3V RS232 estaría bien.

¿Alguien ha intentado algo como esto? Estoy un poco preocupado por la capacidad de un cable USB de 3 m que causa problemas. Ninguno de estos protocolos seriales es diferencial, pero debe hacer frente a los bordes de señal deficientes. Puede obtener controladores de línea para I2C / SPI / TTL-RS232 pero los que he visto parecen interferir con el USB cuando no están en uso. Pensando en ello, I2C sin un controlador de línea podría ser problemático debido a la necesidad de resistencias pull-up.

Después de investigar un poco, me inclino hacia 3.3V RS232. Podría usar SPI pero los protocolos síncronos pueden tener problemas con un cable de 3 m a altas velocidades. Si el receptor genera el reloj, habrá un retraso antes de que el remitente lo vea y llegue la respuesta. Si el remitente genera el reloj, no habrá ningún problema con el retraso (ya que los datos se retrasarán en la misma cantidad), pero complica algo las comunicaciones de dos vías. La otra desventaja de SPI es la falta de bits de inicio / parada, pero generalmente no es un problema porque puede usar una línea de habilitación para iniciar la comunicación en un punto conocido, pero no tengo suficientes líneas para una.

Nuevamente, ser cronometrado puede valer el esfuerzo adicional en el lado del protocolo en orden, ya que debería ser más robusto con la degradación de la señal. Las resistencias de terminación deberían ayudar a lidiar con las reflexiones.

En cualquier caso, una velocidad razonablemente alta debería ser posible. La Playstation de Sony usa SPI a 3.3 v con un reloj de 500 KHz y funciona bien con cables largos. El N64 usa una sola línea de datos aysnc (sin reloj) a aproximadamente 333 KHz, nuevamente en clientes potenciales largos.

    
pregunta user

2 respuestas

2

Mi consejo es usar un UART y RS485.

Si intenta utilizar cualquier protocolo de señalización no diferencial en un cable tan largo, obtendrá una BER terrible a tasas de datos útiles. El asíncrono semidúplex diferencial es el camino a seguir.

Sus preocupaciones acerca de compartir el bus con USB son válidas, pero los controladores RS485 pueden (generalmente) ponerse en un modo de alta impedancia que podría estar dispuesto a coexistir con USB.

    
respondido por el markt
-1

Esto se ha hecho en muchas aplicaciones, lo que necesita es un mux que dirija los pines de señal a los pines USB del microcontrolador, o a los pines de la interfaz serie.

De esta manera, las señales siempre terminan donde deberían ir, y los dos buses no pueden interferir entre sí.

Con respecto al protocolo serie, es mejor ir con un bus diferencial (USB es diferencial ...)

Es posible obtener la serie TTL a pocos metros, ¡pero depende mucho de la velocidad y el cableado!

    
respondido por el HenningNT

Lea otras preguntas en las etiquetas