Good idea to use UART in half-duplex mode when using RS485 transceiver?

Question

Most 2-wire RS485 implementations I have seen use both UART RX and TX pins which works of course. And I have done so.

But I was wondering whether using UART in half-duplex mode is a good alternative that maybe(?) has benefit of cleaner code and reducing pin count.

The application is Modbus ASCII and timing is so clear (3.5 characters) that the switchover (that I do for DataEnable anyway) could be joined with a TransmitEnable.

(Some context: I have had RS485 transmitters with local echo’s on the UART RX line)

Answer 1

It might be a good idea if you are in a situation where you need to preserve pins.

But it also then makes some things harder.

You need to switch single MCU pin between RX and TX modes for the single UART wire, in addition of controlling the transmitter/receiver enable pins.

It might also need a pull-up to the data lines so it floats idle between changing direction of MCU pin - some MCUs have internal pull-ups that can stay enabled all the time instead of turning on just when input.

It also makes it impossible to read back what is transmitted by the MCU, so detecting glitches, collisions or errors is not possible.

Answer 2

RS485 already is half-duplex. So, why not introduce a little more to the PHY interface.
It is a good idea if you can find a reliable method to arbitrate RX & TX at local nodes, and arbitration of the bus. Becoming even more proactive, you may introduce a way to detect the contention on the bus. On software side, link layer can happily lose some serious part of the code.
While writing this, it indeed feels like a very interesting idea; something like Ethernet on RS485 PHY, or there must be something already out there.

Answer 3

Hmm... standard Modbus/ASCII does not use a frame break timeout of 3.5 characters worth. That timeout is characteristic of Modbus/RTU. Obviously if you own the implementation of all the nodes, this does not mean much. If your frame RX routine can detect end of frame based on frame contents (variable length frames have the length encoded early in the frame), you probably don't even need to honor the 3.5 characters worth in terms of RX/TX "turning time".

Once upon a time I've written a Modbus library for the PC, and I also happen to know a bit about the 16C550A and compatible UART's - but that knowledge is getting rusty. And I certainly know nothing about UART's occurring in MCU's. Being spoilt by the wasteful approach to pin counts in PC hardware, and having but a rusty fond memory of coding around the 16C550A UART hardware, I don't see what "using the UART in half-duplex mode" could save me in terms of code size or complexity.

That said - if I may suggest something to facilitate half-duplex RS485 operation, it would be using an UART that can steer the RX/TX automatically, by exporting the internal flag called "Transmitter Shift Register Empty" as an external discrete signal, which can be plugged directly into the RS485 level shifter (transceiver).

Note: do not confuse the desired "Transmitter Shift Register Empty" with the "Transmitter Holding Register Empty" = a different status flag in the UART. The former means the byte being currently shifted bitwise onto the line. The latter refers to the FIFO - and the THRE flag becomes active as soon as the FIFO is empty, i.e. while the shift register is still busy shifting out the last byte, i.e. too early for the RS485 transceiver to get disengaged into high Z / listening state.

Some UART implementations can send this signal as an alternative function of the RTS or DTR pins, others have dedicated output pins or can map this to some GPIO. The standard 16C550A only has the TSRE aka TEMT as an internal status flag, but lacks the capability to export this on any output pin. I.e. the 16C550A is not a stellar choice for RS485. As a shiny example of this function done right, I'd like to mention the late OX16C950 UART by Oxford Semiconductor, nowadays no longer manufactured (technical progress has its underside, and there was a string of acquisitions, roughly OX Semi -> PLX -> Avago -> Broadcom). If memory serves, modern UART's by EXAR can do it too, and some LPC SuperIO chips can also support this on some or all UART channels (Fintek, SMSC, maybe some recent ITE and Nuvoton nee Winbond). I don't have a clue about UART's in the various MCU's.

I seem to recall some UART's where this function is flawed - namely I recall an addon PCI board for the PC, with RS485 ports and HW steering, where the UART would switch the transceiver to high-Z (RX) one bit too early, effectively cutting off the stop bit. Which apparently worked fine against other UART's... I don't remember the brand of the UART chip on that board.

I've also seen a board-level design bug (thinko) in some asian industrial PC, where RS485 mode was implemented by driving the transceiver's RX/TX steering pin by the UART's TTL Data TX - so that the transceiver was switching between log.1 and high Z...

This feature, i.e. "TSRE=TEMT for RS485 RX/TX steering" can save you some headache with precise timing in software. It sure is a headache on the PC, especially under some modern OS... whether timing is a headache or not on your particular MCU, that's obviously your own business, YMMV.