¿El convertidor RS 485 a RS 232 cambiará el modo semidúplex al modo dúplex completo?

Estoy usando una conexión serie RS 485 a través de la cual necesito enviar archivos S19 para mi proyecto de cargador de arranque. Dado que es un modo de conexión semidúplex, necesito alternar un pin dedicado antes de enviar y recibir. Estoy usando esta aplicación de terminal. Obtuve el resultado deseado cuando envié una cadena.ingrese la descripción de la imagen aquí

Pero no pude obtener ningún resultado cuando intento cargar un archivo (archivo s19 para ser específico). ¿Es por la conexión Half-Duplex que uso? ¿Un convertidor de RS 485 a RS 232 cambiará el modo de medio dúplex a dúplex completo?

ACTUALIZAR

Estoy trabajando en el microcontrolador MKE02Z64VLD2 de Freescale. Acabo de enterarme de que no hay un pin RTS CTS en mi controlador. (Consulte el enlace de comentario 1)

Esta es la conexión serial que uso,ingrese la descripción de la imagen aquí

Y la aplicación Terminal no es una GUI de cargador de arranque, la encontré en este sitio. (Consulte el enlace del comentario 2) Gracias por ayudar. Estoy publicando los enlaces en la sección de comentarios porque no tengo suficiente reputación para publicar más de 2 enlaces.

¿Tienes CTS conectado? De lo contrario, debe cambiar el protocolo de enlace a 'ninguno' o 'xon/xoff'. De lo contrario, la PC no enviará porque no cree que el otro extremo esté listo para recibir datos.
Suena como un protocolo, así como un problema de falta de coincidencia de hardware. Para que esto funcione, necesitará una comprensión profunda de los datos de su s19 en términos de protocolos de señal, de lo que tal vez pueda escribir un código para una interfaz adecuada. ¿Qué sucede exactamente cuando envías una cadena? Mira en los detalles finos. Es posible que deba hacer algunos ataques de bits para que esto funcione.
@BruceAbbot. Gracias, intentaré cambiar el Handshaking a cualquiera de los 2 y buscaré la salida.
@Sparky256 Este es mi código que envía la cadena para (;;) { GPIO_PDD_TogglePortDataOutputMask(GPIOA_BASE_PTR, GPIO_PDD_PIN_21); CLS1_SendStr("¡Hola mundo!\r\n", CLS1_GetStdio()->stdOut); WAIT1_Waitms(1000); CLS1_SendStr("¡Bienvenido Ganesh!\r\n", CLS1_GetStdio()->stdOut); Esto me da la salida deseada.
"Obtuve el resultado deseado cuando envié una cadena... Pero no pude obtener ningún resultado cuando intento cargar un archivo (archivo s19 para ser específico)". Los archivos S19 son cadenas. Entonces, su problema no es que su cargador de arranque no pueda recibir el archivo s19, sino cómo procesa los datos. Si no tiene control de flujo (xon/xoff, o RTS/CTS si está disponible), es posible que el cargador de arranque no pueda mantenerse al día con la velocidad de datos entrantes mientras escribe en Flash al mismo tiempo.
Borre eso: en el enlace 1 admite que tampoco puede obtener una respuesta cuando envía una cadena. Quizás la MCU esté recibiendo la cadena, o quizás no. Pero no lo sabrías porque tienes 'while(1);' antes de enviar la respuesta.

Respuestas (2)

No. Un convertidor simplemente cambia la señalización eléctrica y le brinda un control explícito (generalmente reutilización de la línea de control del módem) o automático (basado en el tiempo) de la habilitación de transmisión.

La adaptación a un esquema semidúplex debe ser realizada por el software en cada extremo.

En cuanto a por qué falló exactamente su configuración, es imposible responder con la información limitada proporcionada, sin embargo, el software que no está escrito con este modo de comunicación en mente podría ser una parte clave del problema.

En este punto, debe ampliar su pregunta con más detalles: ¿qué placa MCU usa, qué transceptor rs485 usa (cableado), en el lado de la PC, qué convertidor RS232 / 485? Si su cargador de arranque (PC y MCU) funciona en semidúplex, la PC envía datos y espera ACK de MCU, la MCU espera datos y después de recibirlos envía ACK, nunca existe comunicación en ambas direcciones. Solo entonces puede configurar el terminal para usar RTS en TX; esto implica que el convertidor rs232/485 usa RTS de rs232 para habilitar/deshabilitar la transmisión en rs485 (es un convertidor específico). Se debe hacer lo mismo en MCU, en lugar de usar el comando de alternar usar set/reset. El éxito está en duda en cualquier momento, si no tiene acceso completo para parchear el cargador de arranque agregando tiempos de espera adicionales, hw handsake, etc. ¿La ventana de terminal en su imagen es una GUI de cargador de arranque?

He ampliado la pregunta señor. No he realizado ningún cambio en el código del cargador de arranque con respecto a Half Duplex. Escribí el código pensando que es una conexión dúplex completa. Pero más tarde, cuando probé el código, solo descubrí que me perdí el problema principal aquí (que es medio dúplex). Entonces pensé en probar códigos simples para enviar y recibir cadenas y luego intentar enviar un archivo .s19. Si tengo éxito con eso, puedo incorporar la misma lógica en mi código del cargador de arranque. ENLACE 1: community.freescale.com/message/643594#comment-643594 ENLACE 2: sites.google.com/site/terminalbpp
No estoy familiarizado con esos dispositivos, pero una posible solución fácil es configurar RTS, luego transferir los datos para enviarlos en un fifo que está vinculado con DMA-> UART_TX, y buscar si el DMA es capaz de emitir una interrupción cuando el fifo está vacío ( significado ha enviado todos los caracteres), en ese momento reinicia el RTS
Ahí es donde radica el siguiente problema. Los modos RTS y DMA están disponibles en mi IDE (Kinetis Design Studio), pero el controlador (MKE02Z64VLD2) para el que estoy diseñando el cargador de arranque no es compatible con CTS, RTS.
Sí, lo tengo. Llamémoslo TX_EN en su lugar (un GPIO), ahora cambie mi comentario anterior, RTS con TX_EN. Configure la transmisión a través de DMA y configure la interrupción en DMA Tx fifo vacío.
No necesita DMA para mantenerse al día con una velocidad de transmisión moderada como la 38400 que se muestra (o incluso 115200), y tratar de usarla probablemente solo haga que administrar la dirección del enlace sea más complicado, especialmente para alguien con la aparente inexperiencia del autor de la pregunta.
@ChrisStratton Lo que OP necesita es una interrupción que después de que se envíen todos los caracteres, en ese momento un pin GPIO (TX_EN) tiene que bajar. Antes de enviar los caracteres a UART, sería necesario configurar GPIO alto. Eso es todo. Ahora no encuentro las palabras adecuadas para explicarlo.
Sí, aunque una de las cosas a tener en cuenta es la diferencia entre el estado o la condición de interrupción que indica que el transmisor puede aceptar una nueva palabra de datos (que es lo que suele ser interesante), frente a la que indica que realmente ha terminado. desplazándose hacia el cable: para este esquema, este último es lo que se necesita para desactivar el controlador de transmisión.