Diferente comportamiento de FTDI USB RS485 en diferentes computadoras

Uso un cable adaptador FTDI USB-RS485 para conectar un dispositivo RS-485 a una computadora.

La comunicación es bastante simple, la computadora envía solicitudes periódicas, el dispositivo las responde.

En una computadora (portátil Dell, Win XP) esto funciona como se esperaba, pero con otra (portátil Fujitsu, Win XP) tengo algunos problemas.

Cada par de solicitudes, el dispositivo no las responde y reclama un error de paridad. Por lo que vemos con PortMon y un osciloscopio, las solicitudes son siempre las mismas, por lo que deben responderse.

La aplicación en las computadoras portátiles es exactamente la misma y todos los controladores (CDM 2.08.24) son iguales. Una diferencia es que la computadora portátil problemática tenía instalada una versión anterior del controlador.

¿Alguna pista de lo que debo revisar?

Editar:

Entonces, investigamos el problema un poco más: 2 computadoras portátiles funcionan bien (HP, Dell, ambas WinXP e Intel Centrino), otras tres no funcionan (2 Fujitsu, Sony, WinXP, Win7, todas Intel i5 o i7).

Medimos las señales con un osciloscopio, que se envían al dispositivo. Las computadoras portátiles que no funcionan envían señales, que oscilan entre 3 y 6 microsegundos. Entonces asumimos que el dispositivo no puede reconocer los bits correctos debido a esa fluctuación. Usamos diferentes cables FTDI USB-RS485, pero siempre con los mismos síntomas. Las computadoras portátiles que funcionan tienen una fluctuación de máx. 1 microseg.

Entonces mi pregunta: ¿por qué tiembla la señal transmitida por el cable en algunas computadoras, en otras no?

También nos pusimos en contacto con el soporte de FTDI, pero todavía no hubo una respuesta suficiente.

Edit2:

Hasta ahora tenemos 2 computadoras portátiles que funcionan y varias que no funcionan. Parece que las computadoras portátiles más antiguas con cosas de Centrino funcionan, hasta ahora ninguna computadora portátil más nueva con CPU Intel i5 / i7 funcionó.

Sospechábamos que no hay un reloj interno en el adaptador y que el adaptador usa un reloj de la computadora portátil, pero el soporte de FTDI confirmó que el adaptador tiene su propio reloj interno. El soporte de FTDI no ha oído hablar de este problema en el pasado y hasta ahora no tiene una solución.

Ya ha recibido dos respuestas potencialmente útiles y comentarios de seguimiento posteriores, pero no se ha molestado en votar a favor de nada. Si lo hace, es más probable que continúe obteniendo respuestas. Con respecto a su actualización, tal vez un problema de velocidad completa versus alta velocidad, pero no lo sé.
Debe hacer un esfuerzo para diferenciar entre la fluctuación dentro de un carácter determinado (que es mala y debe contenerse dentro de los límites) frente a la fluctuación en el tiempo entre los caracteres, que cualquier receptor debe tolerar sin límite superior.
El jitter está dentro de un carácter dado, por lo que el dispositivo no lo tolera.
Verifique la conexión a tierra de la computadora portátil / fuente de alimentación.

Respuestas (4)

Encontré exactamente el mismo problema: convertidor USB <> RS485 basado en FTDI (la marca es "DIGITUS"), funcionando a 57600 bps, funcionando correctamente en algunas máquinas y en algunas envía grandes cantidades de datos muy, muy poco confiables. Lo que descubrí (después de perder mucho tiempo investigando la conexión a tierra y la terminación del bus) es que en las máquinas rápidas no funcionó, porque el chip del controlador RS485 (no fabricado por FTDI) no liberó el bus RS485 rápido/confiable suficiente en relación con la salida del chip FTDI. FTDI libera el bus después de todos y cada uno de los bytes (justo después del bit de parada) a través del puerto TXEN y lo vuelve a adquirir inmediatamente para el siguiente byte (que en las máquinas rápidas ya está en el búfer). La solución fue poner un retraso entre cada byte enviado y funcionó. Sí, una solución bastante mala. Desearía que FTDI diera una opción, por ejemplo

¿Qué retardo te funcionó? ¿Proporcionó comentarios a FTDI?
Usé 1 milisegundo (desde la programación en un lenguaje superior, haciendo un simple SLEEP (1)). Para la aplicación (conectar cosas incrustadas de desarrollo propio a la PC), no era realmente crítico en cuanto al tiempo, solo molesto por la incertidumbre de cuál podría ser el problema.

Hay dos posibilidades como yo lo veo.

1:
No está anulando por completo los ajustes de configuración del FT232 cuando abre la interfaz serial.

He realizado un trabajo bastante extenso con las interfaces seriales de FTDI, y puedo decirles que es muy posible que una interfaz serial basada en uno de sus dispositivos se encuentre en un estado muy extraño al abrirlo por primera vez. Dependiendo de cómo esté hablando con el puerto (¿lo está tratando como un puerto serie o está usando el controlador D2XX de FTDI?), en realidad tenía un puerto abierto en modo 7E1 (7 bits, incluso paridad, 1 bit de parada) en cada inicialización, a pesar de que nunca lo había usado en esa configuración.

Los valores predeterminados se almacenan utilizando un conjunto completo de claves de registro, pero recomendaría configurar manualmente todas las opciones de configuración del puerto cada vez que abra la interfaz, incluso si está seguro de que la computadora en la que se encuentra tiene los valores predeterminados correctos.

2:
La otra posibilidad que veo es más complicada:

Básicamente, FTDI no fabrica dispositivos USB-RS-485. Solo fabrican dispositivos USB-Parallel y USB-RS232. Como tal, para hacer una interfaz USB-RS485 basada en FTDI, necesita un IC de búfer adicional, que generalmente está controlado por algunas de las líneas IO adicionales en uno de los IC serie USB de FTDI.

Supongo que es posible que algunas de las líneas de control auxiliares en su interfaz USB-RS485 estén configuradas de manera diferente en cada computadora.

Por ejemplo, vea este esquema del convertidor USB-485 de demostración de FTDI :
ingrese la descripción de la imagen aquí

Como puede ver, el estado de CBUS2y CBUS4están involucrados en el manejo de transmisión/recepción y habilitación de recepción respectivamente.

Puedo concebir (aunque es bastante improbable), que la línea de habilitación de transmisión o recepción FS485 esté configurada para usar el pin incorrecto por el controlador en una de las computadoras (puede configurar TXEN y RXEN para que sean cualquiera de CBUS0-CBUS4. Esto podría causar problemas interesantes con las líneas de control flotantes/indeterminadas del IC de la interfaz 485. Sin embargo, esto me parece bastante poco probable.

Lo trato como un puerto serial y uso la biblioteca boost::asio para la comunicación serial.
@Simon: ¿hay alguna forma de probar cosas con el controlador FTDI D2XX?
No es muy fácil, pero estaba considerando usar el controlador D2XX de todos modos (al menos para probar).
Un posible sospechoso en lo que respecta a la habilitación de RS485 sería una sincronización incorrecta de esa señal en relación con los datos, por ejemplo, la desactivación de los datos antes del final de un carácter. Esto podría suceder en algunas computadoras pero funcionar bien en otras, si el esquema para controlarlo hace suposiciones inseguras sobre el tiempo de las operaciones en el bus USB. Aumentar la demora antes de desactivar el conductor (o incluso esperar hasta que lo haya recibido) podría ser una solución, si puede tolerar un largo tiempo de giro del autobús. Pero un convertidor serial personalizado hecho a partir de un micro USB administraría mejor la habilitación.

¿Quizás un problema de calidad de energía? Los chips en adaptadores como ese generalmente son alimentados por la PC.

Puede usar un analizador USB (software o hardware) para descartar problemas de software o controladores.

Gracias por tu sugerencia. ¿Alguna sugerencia para una herramienta de prueba basada en Win?
Ahora sospecho que hay un problema de alimentación, porque el cable necesita 300 mA y en esa computadora portátil específica, varios otros dispositivos internos están conectados a un concentrador interno, por lo que supera los 500 mA. Lo probaré la próxima semana con un concentrador USB con alimentación externa.
Para los analizadores de bus de software de Windows, pruebe USB Snoopy o el Usb Sniffer más nuevo . En Linux, Wireshark funcionará.
Parece que no es un problema de energía, vea la pregunta editada

Hicimos algunas pruebas más en diferentes computadoras portátiles (perdón por el formateo, no descubrí cómo formatear una tabla aquí):

Tipo de portátil | Procesador | Comunicaciones en serie

DELL Precisión M6300 | Intel Centrino | DE ACUERDO

HP EliteBook 6930p | Intel Centrino | DE ACUERDO

Panasonic Toughbook CF-18 | Intel Centrino | DE ACUERDO

Roda Rocky RK9 | Intel Core 2 | DE ACUERDO

Serie Fujitsu Lifebook S | Intel Core i5 | FAIL (incluso en puertos USB3)

Sony Vario | Intel Core i5 | FALLAR

caballos de fuerza | Intel Core i5 | FAIL (incluso en puertos USB3)

Entonces parece que las computadoras portátiles con conjuntos de chips USB para procesadores Intel i no funcionan, las más antiguas sí.

Sin embargo, compré una USB-ExpressCard (lo siento, tienda web alemana) con el chipset Renesas USB 3.0 y con eso la computadora portátil Fujitsu funcionó bien.

Entonces, usar ExpressCards es una solución para nosotros, pero todavía no sé cuál es el problema exacto. El soporte de FTDI parecía no estar al tanto de ese problema.

Diferente comportamiento de FTDI USB RS485 en diferentes computadoras
RespuestasAquíPolítica de privacidad1y, 1v