Estoy diseñando un sistema que necesita hacer comunicaciones en 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 conecta a un sistema integrado, utilizará un protocolo de comunicaciones en serie más simple. El lado USB solo tiene velocidad completa (12 Mb/seg), y las comunicaciones en serie solo necesitan ser de 100 Kb/seg, aunque 1 Mb/seg estaría bien.
El dispositivo independiente utilizará un microcontrolador para las comunicaciones. Tanto el dispositivo como el sistema integrado estarán basados en un microcontrolador, muy probablemente Atmel XMEGA. Una opción sería instalar un dispositivo compatible con USB OTG/host, pero quiero evitar esta complejidad, costo y opciones limitadas de microcontroladores.
Los micros XMEGA tienen periféricos UART y SPI en los mismos pines que USB D+/D-. También podría enrutar I2C desde otros dos pines hacia ellos, y no creo que perjudique la calidad de la señal. Dado que el cable USB solo tiene dos líneas, si usara SPI, sería unidireccional, lo que podría manejar. Sin embargo, I2C bidireccional o 3.3V RS232 estaría bien.
¿Alguien ha probado algo como esto? Estoy un poco preocupado por la capacitancia de un cable USB de 3 m que causa problemas. Ninguno de estos protocolos en serie 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 USB cuando no están en uso. Pensándolo bien, 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 por 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á algún retraso antes de que el remitente lo vea y llegue la respuesta. Si el remitente genera el reloj, no habrá problema con la demora (ya que los datos se retrasarán en la misma cantidad), pero complica un poco las comunicaciones bidireccionales. 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 uno.
Por otra parte, ser cronometrado puede valer la pena el esfuerzo adicional en el lado del protocolo para que sea más robusto con la degradación de la señal. Las resistencias de terminación deberían ayudar a lidiar con los reflejos.
En cualquier caso, debería ser posible una velocidad razonablemente alta. La Sony Playstation usa SPI a 3.3v con un reloj de 500KHz y funciona bien con cables largos. El N64 usa una sola línea de datos aysnc (sin reloj) a alrededor de 333 KHz, nuevamente con cables largos.
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á un BER terrible a velocidades de datos útiles. 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.
Esto se ha hecho en muchas aplicaciones, lo que necesita es un mux que enruta los pines de señal a los pines usb del microcontrolador o a los pines de la interfaz serial.
De esta manera, las señales siempre terminan donde deben ir, y los dos buses no pueden interferir entre sí.
En cuanto al protocolo serie, lo mejor es ir con un bus diferencial (USB es diferencial...)
Es posible conseguir serie TTL a pocos metros, ¡pero depende mucho de la velocidad y el cableado!
usuario
mercado
usuario
mercado
usuario