¿Algo especial que deba saber sobre RS232 y FT232R?

Estoy tratando de conectar una IMU XSens con mi computadora y me encuentro con dificultades interesantes. La IMU tiene un conector RS232 que solo usa los pines VCC, GND, TX, RX, 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 RS232 estándar (y no tengo motivos 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 todas las configuraciones COM de la misma manera (velocidad en baudios, paridad, parada, etc.) y me conecto al dispositivo, obtengo datos, pero parece un galimatías. Ejecuto comandos, el LED TX en el FTDI parpadea, el RX también, y obtengo datos, pero no se parece en nada a lo que esperaba.

¿Alguien puede pensar en algún "error" que me pueda estar perdiendo? ¿Hay un FooBar que deba conectarse al DingDing para actuar?

¿Cuáles son las configuraciones del puerto y a qué lo ha conectado hasta ahora? ¿Era una PC a la que lo conectaste? ¿Es este el dispositivo de 921600 bps en su otra pregunta?
Configuré el dispositivo y el puerto VCOM en 115200, 8 bits, sin paridad, 2 bits de parada, sin xonxoff, sin rtscts, sin dsrdtr. Sí, es el dispositivo en mi otra pregunta. Por el momento usaré una PC, pero me gustaría poner todo el sistema en una caja más adelante.
VCC no es RS232 estándar.
2 bits de parada son poco comunes, el valor predeterminado suele ser un bit de parada.
Acepto 5-30V como su VCC, y usa 2 bits de parada. Sin embargo, he probado con 1 y 2 bits de parada.

Respuestas (5)

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 originalmente era 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 ese chip MAX3160 (aunque es inusual, algo como el max2332 es más común).

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

Creo que esto suena como lo que estoy haciendo mal. Necesitaría uno de esos transceptores. Creo que eligieron el MAX3160 porque alcanza hasta 1 Mbps. ¿Alguien sabe dónde puedo conseguir una sola placa que pueda hacer USB en un extremo y rs232/EIA-232 "verdadero" en el otro? ¿Y ser capaz de alcanzar velocidades de hasta 921600?

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

El estándar RS232 tiene niveles de ±12 V, que generalmente se convierten mediante algún chip MAX en niveles TTL.

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

Lo intentaré de nuevo, pero al leer las especificaciones, ¡los xsens aceptarán 5-30v!
Sí, pero ¿qué emite ?
También tenga en cuenta que la polaridad entre RS232 y TTL está invertida.

Mirando las especificaciones de algunos de los dispositivos en ese sitio, enumeran la interfaz digital como 'max 921600 bps', por lo que, a menos que tenga muy buenas razones para creer que el dispositivo está funcionando a esa velocidad en baudios en particular, valdría la pena su mientras intenta hablar con él a algunas otras velocidades de transmisión, especialmente si tiene una buena idea de cómo se supone que deben verse los datos. Configuraría mi terminal para 115200 y vería si los datos tenían algún sentido a esa velocidad, luego bajaría la escala de velocidad en baudios. Si llega a 9600 y todavía parece un galimatías, vuelva a 115200 y continúe.

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

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

Sí, he probado la mayoría de las velocidades en baudios disponibles para mí. He probado todas las combinaciones stopbit, bytesize, buadrate. Estoy enviando alrededor de 44kB/s a través del cable serial. Sin embargo, como prueba, he intentado reducir la tasa de datos del dispositivo a 8,4 kB/s, y la tasa de baudios a 115200. Con su USB-Serial, todo funciona, con el FTDI, obtengo el mismo galimatías que antes. Puedo configurar el dispositivo a una variedad de velocidades de transmisión, frecuencias de muestreo, etc., pero no he tenido suerte con el FTDI :( ¡Pero gracias!
Una vez me encontré con una situación en la que un puerto basado en USB/FTDI que se suponía que era capaz de 115.2k no podía reproducirse a esa velocidad con cierto dispositivo. En ese caso, el dispositivo funcionó bien cuando se conectó a un puerto com 'real' integrado en la computadora, y el puerto basado en FTDI funcionó con otros dispositivos en 115.2; pero FTDI y ese dispositivo eran solo una combinación patológica de chips de interfaz.
JustJeff, tengo una situación similar con un periférico que integramos en nuestros productos. Funciona bien con el puerto serial de una computadora, pero no con un PIC. Resulta que su tasa de baudios está un poco apagada. Aparentemente, los puertos serie 'reales' son más indulgentes que los microcontroladores. Afortunadamente, el PIC se puede ejecutar a velocidades de transmisión no estándar.
@Jeanne Pindar: sí, también me ha pasado eso. Obtienes un dispositivo que es un poco lento, otro que es un poco rápido y la mayoría de las cosas juegan con la mayoría de las otras cosas. Pero de vez en cuando te das cuenta de que aunque A habla con B y B habla con C, simplemente no puedes hacer que A y C hablen, y sale el O-scopio.

Una molestia que he tenido con los chips FTDI, que probablemente no sea la causa de sus problemas, pero 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 tiene. recibida del dispositivo remoto pero aún no enviada a la PC. Esto puede causar problemas de dos maneras:

  • Algunos dispositivos integrados están inactivos con su salida serial baja; cuando tienen algo que decir, encienden su salida en serie, envían algunos datos y luego vuelven al ralentí bajo una vez que lo han dicho. Si el dispositivo integrado está alimentando algo que puede dormirse cuando su entrada en serie es baja durante un período prolongado y reactivarse cuando sube, 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 (he verificado con un osciloscopio: los datos se enviaron antes de que la línea se interrumpiera, pero el FTDI se cayó de todos modos).

  • Cuando se usa un UART típico que está configurado para una velocidad en baudios más rápida que el dispositivo al que está conectado, generalmente se recibirán 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 enmarcados correctamente y 80, F8 y valores de bytes enmarcados incorrectamente 00 y 78. Recibir muchos de esos valores de bytes particulares puede hacer que es fácil identificar el problema. Desafortunadamente, cada vez que el FTDI ve un 00 enmarcado incorrectamente, es probable que descarte los datos que lo preceden. En consecuencia, en lugar de ver datos basura fácilmente identificables, uno puede terminar sin ver nada.

Por esta razón, entre otras, tengo una especie de relación de amor y odio con los chips FTDI. Los uso, y son razonablemente convenientes en muchos sentidos, pero no son un reemplazo directo tan simple para un UART como uno quisiera.

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

¿Algo especial que deba saber sobre RS232 y FT232R?
RespuestasAquíPolítica de privacidad1y, 1v