How can we use RS-485 in full-duplex ?

[ranran]

Hello,

We need to use RS-485 in full duplex, and with the flow control (DE).

Is it that when we configure DE with RS485 is shall be used as half duplex ?

can I configure rs232 pins with RTS (instead of DE) before converting voltage to rs-485 levels ?

Will this create a full duplex connection ? (CTS shall always be active in order to provide full duplex connection)

Thank you,

ran

[Mon2]

I think there is some confusion on this project.

With this configuration I assume that the controller will remain in full duplex, Right ?

No.

In RS485, you have 2 choices for wiring:

2W = Half Duplex (D+ / D-)

• very common

or

4W = Full Duplex (TX-, TX+, RX-, RX+)

• less common with RS485
• is common with RS422 (this is where DE = always ON; RE = always ON) but is a point to point communication (ie. single node on one side of the wiring + another node on the other side of the wiring - that is all). Each side of the node is terminated with a 120 ohm resistor.

The DE signal you are referencing is the Driver Enable signal for the RS485 transmitter. The polarity of the DE signal varies but is often Active High. Meaning, if DE is HIGH, most RS485 transmitters will be ON (Enabled); if LOW the local RS485 transmitter will be HI-Z (tristate).

RS485 is a multidrop interface meaning that many similar nodes (RS485 transceivers) can camp onto the same 2 wires BUT only one RS485 transmitter can be active at any given time else face data collision / corruption. So only one RS485 transmitter can be enabled to drive the 2 wire line.

Noting this, it is upto you on which GPIO pin is used to toggle the RS485 transmitter's DE pin. RTS and DTR are some common choices but is of course source code defined. This is a CMOS level interface so you must be sure that your CPU pin is also @ 3v3 (common) swing NOT RS232 levels. With RS232 levels, you will risk to damage the RS485 DE and interface pins.

Google for the many many articles on RS485 interfacing and you will find notes on RS485 use with the STM32 series, etc. Also, not all RS485 transceivers are created equal. Reader beware but as it always is the case, you get what you pay for.

What is the baud rate you wish to run with this setup? If < 500kbaud then you should consider SLEW RATE controlled transceiver for the best signal integrity.

How harsh is your environment? If in the lab and controlled then you should be fine without galvanic isolation. If you are working with inductive loads, motors, solenoids, etc. - highly recommend isolation and related protection else you will nuke your RS485 transceivers sooner than you think.

How may nodes do you plan to support? A typical RS485 transceiver is designed, by spec, to support at least 32 similar RS485 nodes. Often, new designed parts are 1/8th load so you can allow for 32*8 = 256 nodes (if each is 1/8th load), in theory.

How long is your wiring? You may need to consider parts with a higher drive than others.

It is very possible to design a circuit to convert RS232 levels to RS485 but do you actually have a RS232 interfaced UART to start with? If not, just consider to use the CMOS levels of your CPU and directly to the RS485 transceiver.

As you can tell - many questions and concerns but suspecting that all you are after is 2W RS485 interface. If in doubt, post more details of your external widget you plan to interface with so we all have a clear idea before you proceed.

[ranran]

Thank you for the comments !

Would it be easier to implement flow control using general gpio ?

We only need the RTS flow control.

Thank you

[Mon2]

The DE pin can be controller by any GPIO pin. RTS is one choice but so is the DTR pin, etc. In the end, the s/w must toggle the respective pin to ENABLE / DISABLE your DE pin of the RS485 transceiver.

Suggest for you to review this application note from ST:

https://www.st.com/content/ccc/resource/technical/document/application_note/52/57/b8/e4/08/38/43/cd/CD00249778.pdf/files/CD00249778.pdf/jcr:content/translations/en.CD00249778.pdf

AN3070

for details on how to manage the flow control. Do use DMA for best results which will permit the process to be automated without having you to nurse the DE pin. That is, many moons ago in the Windows world, it was common practice for the device driver to toggle the RTS pin which was mated with the DE pin to perform this same task. However, this also meant that you could possible have latency issues since the DE pin is slaved to the s/w toggling the pin. It is better to use DMA and allow for the port pin of choice to be toggle autonomously.

Before you dig too deep into this project, please share more details on your "RTS flow control". Is this to allow for your remote device to STOP / GO based on hardware flow control (ie. RTS / CTS?) but is long distance so you are considering to use RS485 transceivers?

This is a lot for someone new to RS485 word to digest but we should all be clear on the concepts before you waste too much time in the wrong direction. Also possible, my mind is getting confused on your project details.

Please confirm:

a) for the mating equipment - what are the electrical levels for the transceiver? Is it already RS485?

b) how far away will this equipment be from the RS485 CPU node?

[Tesla DeLorean]

>>Would it be easier to implement flow control using general gpio ?

Arguably.

The USART CTS/RTS pins can either connect to the USART peripheral, or be GPIO, you get to make the choice, even after you've laid out the circuit.

>>We only need the RTS flow control.

At a USART level the RTS is an output, it connects to the CTS input at the far end. Make sure to have the correct sense.

[Tesla DeLorean · Accepted solution]

A differential driver has two wires (a pair) coming out of it.

If you are doing

TX -> RX

RX <-TX

RTS -> CTS

That's THREE PAIRS using differential drivers.

You and the HW guys need to have a clear understanding of what it is you are doing, and what full and half-duplex mean, you seem confused about pretty basic concepts here.

[ranran]

you're probably right, let me check the stuff more deeply.

Thanks,

[ranran]

This issue is solved.

The HW engineer was a bit too sure of himself :), and made me lose my confidence in myself. This is the reason for my confusion in the above question...

Anyway, he understood that there is NO NEED for flow control at all (in contrast to what he thought all the way)

It is just a gpio for enabling an output device to start transmission!

I apologize for the confusion !