¿Algo especial que deba saber sobre RS232 y FT232R?

5

Estoy tratando de conectar una XSens IMU con mi computadora, y tengo dificultades interesantes. La IMU tiene un conector RS232 que solo usa los pines VCC, GND, TX, RX y nada más. El SDK viene con un adaptador RS232-USB personalizado que usa el FT232R y el MAX3160, pero aparte de eso no parece hacer nada especial.

El fabricante afirma que la IMU usa el estándar RS232 (y no tengo ninguna razón para dudar de ellos), por lo que, para ahorrar espacio (su convertidor es bastante voluminoso), estoy tratando de usar un Sparkfun FTDI Basic Breakout 5V .

Si configuro todos los ajustes de COM del mismo modo (velocidad de transmisión, paridad, detención, etc.), y me conecto al dispositivo, obtengo los datos de vuelta, pero parece ser una tontería. Emito comandos, el LED de TX en el FTDI parpadea, el RX también, y obtengo datos, pero no se parece en nada a lo que estoy esperando.

¿Alguien puede pensar en algún "error" que pueda faltar? ¿Hay algún FooBar que deba estar conectado al DingDing para actuar?

    
pregunta talsit

5 respuestas

11

El estándar rs-232 (como su IMU) y el nivel TTL rs-232 (como el chip FTDI) son diferentes.

El rs-232 estándar cambia entre + V y -V (donde V era originalmente 12, pero ahora la mayoría de los dispositivos funcionarán con voltajes mucho más bajos). El nivel TTL rs-232 cambia entre 0 y 5V. Necesita un transceptor rs-232 para convertir los voltajes, como el chip MAX3160 (aunque es inusual, algo así como el max2332 es más común).

Los convertidores rs-232 de nivel USB a TTL como el que está conectado se usan para conectarse a un microcontrolador, no a un dispositivo rs-232 típico.

    
respondido por el Jeanne Pindar
4

¿Estás seguro de que los niveles de voltaje son compatibles?

El estándar RS232 tiene niveles de ± 12V, que generalmente se convierten con un chip MAX a niveles TTL.

En su caso, la placa de arranque Sparkfun FTDI tiene niveles TTL (0 / 5V), mientras que la MAX3160 puede hacer RS232 y RS485 (!), por lo que hay una falta de coincidencia.

    
respondido por el starblue
3

Al observar las especificaciones de algunos de los dispositivos en ese sitio, enumeran la interfaz digital como 'máx. 921600 bps', así que, a menos que tenga una buena razón para creer que el dispositivo está funcionando a esa velocidad de transmisión en particular, sería valga la pena intentar hablar con otras tasas de baudios, especialmente si tiene una buena idea de cómo deben ser los datos. Configuré mi terminal para 115200 y veré si los datos tenían algún sentido a esa velocidad, luego, bajé la escala de velocidad en baudios. Si llegas a 9600 y todavía parece gibberish, vuelve a 115200 y continúa.

Una tasa de 921600 es casi desconocida. Es un múltiplo estándar, pero honestamente no he visto nada que empuje el RS232 más rápido que el 115200 antes. En el momento en que se hace necesario usar velocidades más rápidas que 115200, los diseñadores generalmente cambian a otra interfaz más confiable.

Por cierto, sigo suponiendo que ha conectado el dispositivo a un puerto de PC y tiene alguna documentación que sugiere cuál es el formato de los datos. Si se trata de una opción para seleccionar una velocidad en baudios, use 115200, será mucho más confiable, asumiendo que es compatible con sus necesidades generales de velocidad de datos.

    
respondido por el JustJeff
1

Una de las molestias que he tenido con los chips FTDI, que probablemente no sea la causa de sus problemas, pero posiblemente podría serlo, es que si el dispositivo remoto envía lo que el FTDI percibe como un "largo descanso", el FTDI descartará la información. que ha recibido del dispositivo remoto pero que aún no se ha reenviado a la PC. Esto puede causar problemas de dos maneras:

  • Algunos dispositivos incrustados están inactivos con su salida en serie baja; cuando tienen algo que decir, activan su salida en serie, envían algunos datos y luego vuelven a ralentí una vez que lo han dicho. Si el dispositivo incorporado está alimentando algo que puede irse a dormir cuando su entrada en serie es baja durante un período prolongado y se despierta cuando está alto, esta función puede proporcionar un medio eficaz de señalización de activación sin necesidad de un pin adicional. Desafortunadamente, el dispositivo remoto que apaga su puerto serie puede hacer que el FTDI descarte la última parte de los datos enviados por el dispositivo (lo he comprobado con un alcance: los datos se enviaron antes de que la línea se cortara, pero el FTDI se cayó). de todos modos).

  • Cuando se usa un UART típico que se configura para una velocidad de transmisión más rápida que el dispositivo al que está conectado, uno generalmente recibirá datos de basura que contienen un subconjunto identificable de posibles valores de byte. Por ejemplo, si uno está configurado para 38,400 y el dispositivo remoto está configurado para 9600, uno recibirá los valores de byte correctamente enmarcados y 80, F8, y los valores de byte incorrectamente enmarcados 00 y 78. La recepción de muchos de esos valores de bytes particulares puede hacer Es fácil identificar el problema. Desafortunadamente, cada vez que el FTDI ve un 00 incorrectamente enmarcado, es propenso a descartar los datos que lo preceden. En consecuencia, en lugar de ver datos de basura fácilmente identificables, uno puede terminar viendo nada.

Por esta razón, entre otras, tengo una relación de amor y odio con los chips FTDI. Los uso, y son razonablemente convenientes en muchos aspectos, pero no son tan simples sustitutos para un UART como a uno le gustaría.

    
respondido por el supercat
1

Si está utilizando su software, asegúrese de cambiar el VID / PID de su FTDI para que coincida con el suyo. De lo contrario, su software no reconocerá su convertidor serial personalizado

    
respondido por el Eric

Lea otras preguntas en las etiquetas