¿Es una buena idea usar UART en modo semidúplex cuando se usa un transceptor RS485?

La mayoría de las implementaciones de RS485 de 2 hilos que he visto usan pines UART RX y TX que, por supuesto, funcionan. Y lo he hecho.

Pero me preguntaba si usar UART en modo semidúplex es una buena alternativa que tal vez (?) tenga el beneficio de un código más limpio y una reducción del número de pines.

La aplicación es Modbus ASCII y el tiempo es tan claro (3,5 caracteres) que el cambio (que hago para DataEnable de todos modos) podría unirse con TransmitEnable.

(Algún contexto: he tenido transmisores RS485 con eco local en la línea UART RX)

¿Cuál es la pregunta?
Es una buena idea usar HDX para facilitar el control y EMI.
Pregunta: buena idea o no. Ya estoy encontrando que es más difícil de depurar

Respuestas (3)

Puede ser una buena idea si se encuentra en una situación en la que necesita conservar pines.

Pero también hace que algunas cosas sean más difíciles.

Debe cambiar el pin MCU único entre los modos RX y TX para el cable UART único, además de controlar los pines de habilitación del transmisor/receptor.

También es posible que necesite un pull-up en las líneas de datos para que flote inactivo entre el cambio de dirección del pin MCU; algunos MCU tienen pull-ups internos que pueden permanecer habilitados todo el tiempo en lugar de encenderse solo cuando se ingresa.

También hace que sea imposible volver a leer lo que transmite la MCU, por lo que no es posible detectar fallas, colisiones o errores.

En realidad, la última declaración no es del todo correcta para todas las MCU. Por ejemplo, en STM32, el USART lee sus propios datos en modo semidúplex siempre que RX esté habilitado, por supuesto. Por otro lado, en STM8, no es necesario deshabilitar RX mientras se transmite en modo semidúplex porque los propios datos no se leen automáticamente.
@neoxic No entendiste lo que escribí. Usted dice que la MCU recibirá exactamente lo que transmite, por lo que no puede detectar fallas, colisiones o errores en el bus RS-485. Quise decir que la MCU transmitirá al bus RS-485 y recibirá lo que está en el bus RS-485, para que pueda ver si recibe lo mismo que envió, o si ha habido errores porque dos dispositivos quieren transmitir simultáneamente en el mismo autobús. Y, por lo tanto, esos errores no se pueden detectar usando un pin MCU solo para RX y TX.
No, no dije que la MCU recibirá exactamente lo que transmite para que no pueda detectar fallas. Dije que depende de una MCU si recibe lo que transmite o no en modo semidúplex. En el primer caso, podrá verificar errores en el bus de un solo cable. En este último caso, NO lo hará.
Entonces, ¿ahora dices exactamente lo que dije originalmente y que afirmaste que no era cierto? no sigo No importa lo que haga la MCU en modo semidúplex, ya sea que reciba transmisiones propias o no, porque cuando se usa un cable UART RX/TX, el lado de la MCU aún no sabe si hay un cortocircuito en el lado RS485, ya que no puede monitorear lo que hay en el lado RS485. Entonces, al usar un cable, en ninguno de los casos, MCU no podrá detectar errores ya que no escuchará los datos reales en RS485.
La capacidad de recibir lo que se envía está diseñada para que una MCU pueda detectar errores y colisiones en la línea. Si hay una colisión (la línea está siendo impulsada por otro TX) o un error (cortocircuito, inestabilidad), es probable que el receptor NO reciba lo que acaba de enviar el TX. Al comparar el último byte enviado con lo que se ha recibido, la MCU puede actuar en consecuencia: cancelar la transmisión, silenciar el receptor, esperar un intervalo aleatorio y reanudar. Pero esta capacidad (para recibir lo que se envía) depende de MCU.
@neoxic Creo que aquí no estamos hablando de lo mismo, o hay algún otro malentendido. Entiendo y reconozco lo que quiere decir en general, pero en este caso, las capacidades de la MCU no importan. Si conecta solo un cable de datos RX/TX semidúplex desde MCU a un chip transceptor RS-485, ya que la pregunta original era sobre cuáles son las desventajas de hacerlo, simplemente no puede obtener comentarios. Para obtener retroalimentación del bus durante la transmisión, los cables TX y RX de la MCU deben estar conectados al transceptor RS-485.
Tal vez. Déjame adivinar... Para mí, el RS485 de 2 hilos es justo lo que es: una capa física semidúplex en la que se utiliza un UART como controlador lógico. Si está hablando de un esquema en el que el UART en una MCU se conecta a un "transmisor RS485" separado (es decir, con su propio UART/controlador), entonces probablemente esté hablando de la conexión entre ellos. Esa conexión no tiene nada que ver con RS485 porque conecta dos periféricos de forma lógica. En este caso, probablemente no haya nada que ganar con el modo semidúplex.
Pero si el UART en una MCU maneja una línea RS485 de 2 hilos directamente, en modo semidúplex lee lo que transmite y, por lo tanto, es capaz de detectar fallas y errores. Por cierto, esta función está diseñada específicamente para aplicaciones RS485. Pero, como mencioné anteriormente, no todas las MCU, o más bien no todos los periféricos UART, lo tienen.
La pregunta original no era sobre un "chip transceptor RS-485". Se trataba de "implementaciones RS485 de 2 hilos que usan ambos pines RX/TX de un UART". Consulte la respuesta n. ° 3, por ejemplo, donde el que responde se refiere a ella como una interfaz PHY (física). 2 hilos significa que es semidúplex.
No, de eso no se trata la pregunta, léala de nuevo. OP ha usado MCU con cables RX y TX conectados a RS-485 PHY, y pregunta si es una buena idea reducir el número de pines de MCU y tal vez cambiar a usar un solo cable RX/TX semidúplex entre MCU y RS-485 PHY y definitivamente pensando en combinar pines RE/TE. Al usar semidúplex entre MCU y RS-485 PHY, la desventaja es que no puede recibir/monitorear/detectar desde RS-485 PHY lo que realmente sucede en el bus RS-485 mientras se transmite al bus con RS-485 PHY.
Ahhh, dispara...:-) Ahora puedo ver dónde estaba el malentendido. ¡Gracias! Sí, la combinación de pines RE/DE en el controlador definitivamente reducirá la retroalimentación.
En aras de la integridad, también debo renunciar a mi comentario inicial. Le di al UART en STM8 una prueba exhaustiva y parece ser igualmente capaz de recibir sus propios datos en modo semidúplex. De hecho, es el mismo UART que en STM32.

RS485 ya es semidúplex. Entonces, ¿por qué no introducir un poco más a la interfaz PHY?
Es una buena idea si puede encontrar un método confiable para arbitrar RX y TX en los nodos locales y el arbitraje del bus. Al volverse aún más proactivo, puede introducir una forma de detectar la contención en el bus. En el lado del software, la capa de enlace felizmente puede perder una parte importante del código.
Mientras escribo esto, de hecho se siente como una idea muy interesante; algo como Ethernet en RS485 PHY, o debe haber algo ya disponible.

RS-485 NO es semidúplex. Puede operar en medio dúplex (una dirección) o dúplex completo (bidireccional) a discreción del diseñador. De hecho, uno de los cambios realizados con el '485 del '422 es que un controlador RS-485 puede controlar un par diferencial que tiene doble terminación, con resistencias de 120 ohmios en cada extremo de la línea.
¡Gracias @SteveSh! Eso suena como un buen argumento con el que puedo estar de acuerdo. De hecho, el estándar puede indicar solo las especificaciones eléctricas de RS-485 y RS-422, supongo que no es necesario limitar el dúplex o los protocolos.
Escucharse a sí mismo hablar no es una forma confiable de detectar contención en un bus RS485.
Estoy de acuerdo con @brhans. La detección de contención no es tan simple.
@SteveSh, quise decir RS485 de dos hilos (mencionado), por lo tanto, contexto de medio dúplex. otros: escucharte hablar en el autobús era algo que quería omitir por completo. Por lo tanto, la idea de usar también el medio dúplex completo en el UART (hará pull-up como se mencionó). No estoy seguro si puedo combinar RX/TX del transceptor 485 así
@ JeromeBu1982 Acerca de "simplemente combine RX/TX" y "eleve las líneas de datos para que flote inactivo": si el pin UART TX no se puede configurar como drenaje abierto, entonces necesitaría un búfer externo. El dispositivo transceptor necesitará una consideración similar. La implementación inicial no sería tan simple como "simplemente ensamblar", aunque si el concepto se implementa en el diseño de dispositivos, sería una opción atractiva, tan simple como RS485 y creo que las respuestas a Ethernet pueden no serlo.
Re: detección de contención: recuerdo una excursión de cuando solíamos vender hardware Westermo. Tienen/tenían una familia de convertidores serie a fibra óptica que pueden/podrían funcionar en un anillo redundante en la fibra. Es decir, creo que esta era la generación anterior de LD-64. El protocolo en el sitio era algo basado en RS485 semidúplex, con paso de token y conmutación rápida de RX/TX. Mientras se iniciaba, aparentemente el autobús se basó en la detección de colisiones (errores de suma de verificación) para retroceder con la transmisión por un tiempo, para "encajar" sin problemas. Los nodos de Westermo impedían que los marcos se distorsionaran y el inicio fallaba...
(...continuación) Yo no llamaría a esto un error , sino un problema de integración. Si no recuerdo mal, los finos nodos del anillo de fibra de Westermo darían prioridad a los datos provenientes de la caída metálica local. En el anillo, los datos viajarían en círculo. Si un "cliente" metálico local comenzaba a transmitir algo, el nodo convertidor de fibra bloquearía lo que viniera del lado izquierdo del anillo y comenzaría a repetir la actividad desde la caída metálica local. Por lo tanto, los nodos descendentes (clientes) a la derecha no detectarían necesariamente un error de suma de verificación de trama y tratarían de realizar un seguimiento directamente.
(...continuación) Esto probablemente condujo a una división/bifurcación/caos en la secuencia de paso de tokens, y el algoritmo ordenado y rápido de paso de tokens colapsaría. Hubo una solución alternativa que ayudó: prestar atención al orden de las direcciones de los nodos en el protocolo "cliente" (la charla del PLC) y ordenar las direcciones de los nodos del PLC a lo largo del anillo en dirección inversa . De esa manera, el nodo vecino a seguir sería el que queda a la izquierda y, con un poco de suerte, cualquiera que esté en el medio (a su derecha) probablemente no intervendría... Los retrasos de propagación a lo largo del anillo de fibra fueron insignificantes = no problema.
¡Buen punto @frr! La "topología de anillo" elimina el arbitraje de "bus"

Hmm... Modbus/ASCII estándar no utiliza un tiempo de espera de interrupción de cuadro de 3,5 caracteres. Ese tiempo de espera es característico de Modbus/RTU. Obviamente, si posee la implementación de todos los nodos, esto no significa mucho. Si su rutina de RX de cuadro puede detectar el final del cuadro en función del contenido del cuadro (los cuadros de longitud variable tienen la longitud codificada al principio del cuadro), probablemente ni siquiera necesite respetar los 3,5 caracteres en términos de "tiempo de giro" de RX/TX. ".

Érase una vez que escribí una biblioteca Modbus para la PC, y también sé un poco sobre el 16C550A y los UART compatibles, pero ese conocimiento se está oxidando. Y ciertamente no sé nada sobre los UART que ocurren en los MCU. Siendo mimado por el enfoque derrochador del conteo de pines en el hardware de la PC, y teniendo solo un recuerdo oxidado de la codificación alrededor del hardware UART 16C550A, no veo qué podría ahorrarme "usar el UART en modo semidúplex" en términos de tamaño o complejidad del código.

Dicho esto, si puedo sugerir algo para facilitar la operación RS485 semidúplex, sería usar un UART que pueda dirigir el RX/TX automáticamente , exportando el indicador interno llamado "Transmitter Shift Register Empty" como una señal discreta externa, que se puede conectar directamente al cambiador de nivel RS485 (transceptor).

Nota: no confunda el "registro de desplazamiento del transmisor vacío" deseado con el "registro de retención del transmisor vacío" = un indicador de estado diferente en el UART. Lo primero significa que el byte se está desplazando bit a bit en la línea. Este último se refiere al FIFO, y el indicador THRE se activa tan pronto como el FIFO está vacío, es decir, mientras el registro de desplazamiento todavía está ocupado desplazando el último byte, es decir, demasiado pronto para que el transceptor RS485 se desconecte en alto Z / escucha estado.

Algunas implementaciones de UART pueden enviar esta señal como una función alternativa de los pines RTS o DTR, otras tienen pines de salida dedicados o pueden asignar esto a algún GPIO. El 16C550A estándar solo tiene el TSRE, también conocido como TEMT, como un indicador de estado interno, pero carece de la capacidad de exportarlo en cualquier pin de salida. Es decir, el 16C550A no es una elección estelar para RS485. Como un brillante ejemplo de esta función bien hecha, me gustaría mencionar el último UART OX16C950 de Oxford Semiconductor, que hoy en día ya no se fabrica (el progreso técnico tiene su lado negativo, y hubo una serie de adquisiciones, aproximadamente OX Semi -> PLX - > Avago -> Broadcom). Si la memoria funciona, los UART modernos de EXAR también pueden hacerlo, y algunos chips LPC SuperIO también pueden admitir esto en algunos o todos los canales UART (Fintek, SMSC, tal vez algunos ITE recientes y Nuvoton nee Winbond). Yo no'

Me parece recordar algunos UART donde esta función es defectuosa, es decir, recuerdo una placa PCI adicional para la PC, con puertos RS485 y dirección HW, donde el UART cambiaría el transceptor a alta Z (RX) un poco demasiado pronto, efectivamente cortando la broca de tope. Lo que aparentemente funcionó bien contra otros UART... No recuerdo la marca del chip UART en esa placa.

También he visto un error de diseño a nivel de placa (thinko) en una PC industrial asiática, donde el modo RS485 se implementó al impulsar el pin de dirección RX/TX del transceptor por el TTL Data TX de UART, de modo que el transceptor estaba cambiando entre registro. 1 y alto Z...

Esta característica, es decir, "TSRE=TEMT para dirección RS485 RX/TX" puede ahorrarle algunos dolores de cabeza con la sincronización precisa en el software. Seguro que es un dolor de cabeza en la PC, especialmente en algunos sistemas operativos modernos... ya sea que el tiempo sea un dolor de cabeza o no en su MCU en particular, obviamente es asunto suyo, YMMV.

Tienes razón: UTR
¿Es una buena idea usar UART en modo semidúplex cuando se usa un transceptor RS485?
RespuestasAquíPolítica de privacidad1y, 0v