Circuito para retrasar el cierre del pin RS-232 TX después del encendido del dispositivo

0

Tenemos dos dispositivos conectados a través de un cable, una computadora basada en ARM en un lado y un sensor en el otro. Este cable lleva un RS232 TX, RX y tierra. Además, el sensor proporciona 28V a la computadora ARM. Cuando el sensor está encendido, proporciona alimentación a la plataforma ARM para que ambos sistemas se enciendan al mismo tiempo.

Se observó que, en esta configuración, el sensor se niega a comunicarse con el procesador. Si el procesador se enciende unos segundos después del sensor, la comunicación funciona normalmente.

Una traza de O-scope mostró que cuando se encendió el procesador, el RS232 TX pasa de ser indefinido a 0 y luego pulsa inmediatamente a 1 y luego vuelve a 0. Creo que si este pulso ocurre durante el arranque de los sensores esto hará que el sensor ignore cualquier IO futura.

La solución simple sería deshabilitar la línea de TX durante unos segundos mientras se inician ambos sistemas. ¿Cuál es el circuito más simple que podría usarse para realizar esto? Este circuito debería estar integrado en el cable.

He visto un montón de circuitos de encendido y apagado en este sitio, pero la mayoría de ellos parece estar cambiando de alimentación, no estoy seguro de si sería diferente si se tratara de una línea IO.

    
pregunta kuhnto

2 respuestas

2

Parece que tiene fallas en las señales de serie en el encendido. Esto no es inusual y debe esperarse.

En lugar de intentar retrasar la alimentación del procesador, su firmware debería hacer los retrasos adecuados y asumir que el otro dispositivo se encuentra en alguna parte arbitraria de su protocolo de comunicación. Este debería ser el procedimiento normal para un sistema integrado que se comunica con dispositivos remotos a través de una serie.

Por lo general, el sistema incorporado inicia su UART, espera unos 100 ms y drena y descarta todos los caracteres recibidos. Luego envía una secuencia para poner el dispositivo remoto en un estado conocido independientemente del estado en el que se encuentre actualmente. Esto podría estar enviando una cadena de NULL más larga que el comando más largo, enviando algunos CR / LF en secuencia, esperando algunos arreglos tiempo, etc. Los detalles dependen en gran medida del protocolo de comunicación de nivel de byte y superior.

En cualquier caso, este es un problema de firmware. No intentes arreglarlo con un paquete de hardware.

    
respondido por el Olin Lathrop
0

La capa física de una señal RS232 utiliza un cambio de voltaje que es incompatible con voltajes de nivel lógico comunes utilizados en computadoras y procesadores integrados. Esto podría ser la causa de un comportamiento inesperado.

La capa de protocolo de una señal RS232 deja mucho que desear . Sin mencionar funciones poco utilizadas que pueden estar interfiriendo con sus comunicaciones que pueden o no haber sido implementado en los dispositivos que está utilizando.

Antes de recurrir a una solución de hardware, intentaría enviar un RS232 break señal del procesador al el sensor.

Si está utilizando la capa física real RS232, es difícil cambiar con lógica porque el cambio de voltaje es mayor que los niveles de potencia lógica normal. Puede consultar relés, relés de estado sólido o interruptores bilaterales.

Si está utilizando señales RS232 de nivel lógico ... Bueno, está utilizando el procesador ARM de alguien (FREESCALE.COM, NXP.COM, TI.COM, ect). Tales chips son generalmente muy configurables. Simplemente designe el pin RS232 TX como entrada GPIO hasta que esté listo para enviar datos reales.

    
respondido por el st2000

Lea otras preguntas en las etiquetas