¿Hay algo especial que deba saber sobre RS232 y FT232R?

Question

Estoy tratando de interconectar un XSens IMU con mi ordenador, y me estoy encontrando con interesantes dificultades. La IMU tiene un conector RS232 que sólo utiliza los pines VCC, GND, TX, RX, nada más. El SDK viene con un adaptador personalizado RS232-USB que utiliza el FT232R y el MAX3160, pero aparte de eso no parece hacer nada especial.

El fabricante afirma que la IMU utiliza el estándar RS232 (y no tengo motivos para dudar de ellos), así que, para ahorrar espacio (su convertidor es bastante voluminoso), estoy intentando utilizar un Sparkfun FTDI Basic Breakout 5V .

Si configuro todos los parámetros del COM de la misma manera (velocidad de transmisión, paridad, parada, etc.) y me conecto al dispositivo, obtengo datos, pero parece un galimatías. Si emito comandos, el LED TX del FTDI parpadea, el RX también, y obtengo datos, pero no es nada de lo que espero.

¿Se le ocurre a alguien alguna "pega" que pueda estar pasando por alto? ¿Hay que conectar una FooBar al DingDing para que actúe?

Answer 1

Mirando las especificaciones de algunos de los dispositivos en ese sitio, enumeran la interfaz digital como "máximo 921600 bps" - así que a menos que tengas una muy buena razón para creer que el dispositivo está operando a esa tasa de baudios en particular, valdría la pena que intentaras hablar con él a otras tasas de baudios, especialmente si tienes una buena idea de cómo se supone que son los datos. Yo pondría mi terminal a 115200 y vería si los datos tienen sentido a esa velocidad, luego, trabajaría hacia abajo en la escala de velocidad de baudios. Si llegas a 9600 y sigue pareciendo un galimatías, vuelve a 115200 y trabaja hacia arriba.

Una tasa de 921600 es casi inaudita. Es un múltiplo estándar, pero honestamente no he visto nada que empuje a RS232 más rápido que 115200 antes. En el momento en que se hace necesario utilizar tasas más rápidas que 115200, los diseñadores suelen cambiar a alguna otra interfaz más fiable.

Por cierto, sigo asumiendo que has conectado el dispositivo a un puerto com del PC y que tienes alguna documentación que te sugiera cuál es el formato de los datos. Si es un opción para seleccionar una velocidad en baudios, utilice 115200, será mucho más fiable, suponiendo que sea compatible con sus necesidades generales de velocidad de datos.

Answer 2

¿Está seguro de que los niveles de tensión son compatibles?

El RS232 estándar tiene niveles de ±12V, que suelen ser convertidos por algún chip MAX a niveles TTL.

En tu caso, la placa FTDI de Sparkfun tiene niveles TTL (0/5V), mientras que el MAX3160 puede hacer RS232 y RS485 (!), por lo que hay un desajuste.

Answer 3

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

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

Los convertidores de USB a rs-232 de nivel TTL como el que has enlazado se utilizan para conectar a un microcontrolador, no a un dispositivo rs-232 típico.

Answer 4

Si estás usando su software, asegúrate de cambiar el VID/PID de tu FTDI para que coincida con el suyo. De lo contrario, su software no reconocerá tu convertidor serie personalizado

Answer 5

Una molestia que he tenido con los chips FTDI, que probablemente no sea la causa de tus problemas pero que potencialmente podría serlo, es que si el dispositivo remoto envía lo que el FTDI percibe como una "pausa larga", el FTDI descartará la información que ha recibido del dispositivo remoto pero que aún no ha sido enviada al PC. Esto puede causar problemas de dos maneras:

• Algunos dispositivos embebidos están en reposo con su salida serial baja; cuando tienen algo que decir, encienden su salida serial, envían algunos datos, y luego vuelven a estar en reposo bajo una vez que lo han dicho. Si el dispositivo embebido está alimentando algo que puede ir a dormir cuando su entrada serie está baja durante un período prolongado y despertar cuando se pone alta, esta característica puede proporcionar un medio eficaz de señalización de despertar sin requerir un pin adicional. Desgraciadamente, el dispositivo remoto que apaga su puerto serie puede hacer que el FTDI pierda la última porción de los datos enviados por el dispositivo (lo he comprobado con un osciloscopio - los datos fueron enviados antes de que la línea se muriera, pero el FTDI los perdió de todos modos).

• Cuando se utiliza una UART típica que está configurada para una tasa de baudios más rápida que la del dispositivo al que está conectada, uno generalmente recibirá datos basura que contienen un subconjunto identificable de posibles valores de bytes. Por ejemplo, si uno está configurado para 38.400 y el dispositivo remoto está configurado para 9600, uno recibirá valores de bytes correctamente enmarcados y 80, F8, y valores de bytes incorrectamente enmarcados 00 y 78. Recibir muchos de esos valores de bytes en particular puede facilitar la identificación del problema. Desafortunadamente, cada vez que el FTDI ve un 00 con marco incorrecto, es propenso a descartar los datos que lo preceden. En consecuencia, en lugar de ver datos basura fácilmente identificables, se puede acabar viendo nada.

Por esta razón, entre otras, tengo una relación de amor-odio con los chips FTDI. Los uso, y son razonablemente convenientes en muchos aspectos, pero no son un simple reemplazo de una UART como uno podría desear.