On Wed, 24 Mar 2021 06:17:46 -0700, Don Y
>On 3/23/2021 10:28 PM, upsid...@downunder.com
>> On Wed, 24 Mar 2021 00:06:21 +0100, pozz <pozz...@gmail.com
>>> I have an half-duplex RS485 bus with 10-20 different nodes. Some of them
>>> are 8-bit MCU based, one of them could be Linux embedded.
>>> It's half-duplex, so it's important for the transmitter node to disable
>>> the driver as soon as the last transmitted bit is shifted out.
>>> Many small low-cost MCU has interrupt on transmission complete, so the
>>> delay of disabling the driver is usually on the order of microseconds.
>> Look very carefully _when_ the interrupt occurs. Some UARTs generate
>> an interrupt when the last character is moved from the FIFO into the
>> shift register, some (also) generate an interrupt, when actually the
>> (last) stop bit has completely shifted out from the shift register.
>> If you turn off the Tx based of the FIFO to shift register interrupt,
>> the Tx can be turned off, while the last character is actually being
>> transmitted and the 'fail safe' termination will pull the line to "1"
>> i.e. idle. The receiver often gets the last character as FF, FE,.. ,
>> F0 etc. especially at low line speeds.
>As you likely have the line connected to the Rx input (to *receive*
>replies), you can use the Rx IRQ to tell you when the character has
>cleared the Tx shift register (and made it out onto the wire).
Yes, I have sometimes used this, but it requires that the Rx path is
always active. Some RS-485 chips disable the Rx side when
transmitting, so you do not hear your own transmission, thus no echo
canceling is required in the software.
>But, you also have to check the timing of that IRQ wrt the actual serial
>data in. Sometimes, the stop bits aren't checked.
>However, anomalies/faults on the line can prevent the Rx interrupt
>from coinciding with the end of the Tx (e.g., if a voltage is effectively
>impressed on the line). The loopback will allow your code to detect that
>transmissions are not happening as expected. But, it will confuse the
>timing of the disabling of the transceiver.
If he line is shorted or connected to Vcc, loosing timing is the
smallest problem :-) Even if the problem is at the remote end of the
cable, the problem must be pretty severe, if you can't detect your own
transmission on the PCB before entering the line.
>A better solution is to route the Tx *pin* on the device to a spare
>Rx pin (another UART) and use that for timing information as it
>is entirely local to the board -- not impacted by faults on the
What is the point of doing loopbacK on TTL, if the RS-485 is bad ?
>>> Some new Cortex-M MCUs have an automatic control of external RS485
>>> transceiver, so the delay is really zero.
>> This is the proper way of doing low latency half duplex. Otherwise,
>> you have to add some extra delay, before the slave starts the
>That's often desirable to let the line "settle" (assuming the software
>is incredibly responsive and the slave receiver was fortunate in how it
>synchronized to the incoming datum). In the real world, folks don't
>always wire things the way they should (e.g., using crappy cable for
>longer than intended runs -- "Wire is wire, right?" :< )
In the Modbus RTU protocol specification it is required to turn on the
transmitter (set to idle "1" state), wait 3.5 character times, then
send the actual message, then keep the transmitter in active idle
("1") state for an other 3.5 character times, before turning off the
transmitter, i.e. put the transmitter into tri-state.
When the transmitter is turned into rtri-state and there are 'fail
safe' pull up/down resistors, the line remains in the idle "1" state
until next transmitter takes over the bus. BTW, the quotes around
'fail safe' termination is in the actual standard text, at least in
If no passive pull up/down resistors are present on the bus, old
signal reflections and external noise will cause some variable unknown
noise voltages on the bus. However, when the next node turns the
transmitter on for 3.5 character times in idle state, after it the
first start bit of the first character is reliably detected.
In Modbus RTU, there is at least 3.5 character times idle period
between actual data transmitter between two stations since it is
perfectly legal for station A to have the trailing 3.5 trailing idle
and station B sends 3.5 preamble on simultaneously. Actually there are
5 (1.5+3.5) character times to turn of the Tx transmitter, since the
Rx uses a 1.5 character time idle period as end of frame marker.
In half duplex communication with short messages, the latencies
between frames will reduce the throughput considerably. With long
messages, the throughput loss is not significant.