Using UART for RS485 HalfDuplex

Hello
I’m looking for informations about the use of an RS485 translator with the UART interface. In detail, for RS485 there is the needing to handle a PIN called DE/REn (example component SN65HVD75). this pin determinates if RS485 transceiver is in TX mode or RX mode.
I’m looking to understand if UART of Jetson Nano handle this pin with RTS (with different behaviour of standard uart). I read this

My question is: could the kernel handle this pin? How to impement RS485? Is there a needing to use a GPIO different from RTS to handle this?

Thanks

The UART handles only 3.3V (though I think it can be selected for 1.8V) logic levels, and so you’d need something to buffer if you really want true RS-485 with its larger voltage ranges and not just something dedicated for 3.3V. Plus RS-485 works with multiple devices, and you’d need logic for that. Haven’t tried it myself, but I found this reference useful since it mentions converting between a UART and actual RS-485:
https://www.cuidevices.com/blog/rs-485-serial-interface-explained

Hello
Tks for reply, but I try to explain me better because the question is not related in how it works but on how to implement direction control for transreceiver.

Take for example a SN65HVD75 or a MAX485 or others similar transreceivers. Take into accont the voltage translation of single ended signals to 3.3V or 5V is done. My question is if the “pin” RTS (that in UART world is a flow control signal) could be “drived” not by physical UART inside the CPU but, like the link I posted, is drived like a GPIO to drive the direction control of the chip.

In other words, is the RTS pin of the UART like a GPIO? Could I control the state never regarding the truth UART-like RTS meaning? Or oppiste, to control the direction pin of the external transceiver I need to use an other GPIO different from RTS pin?

For information on what I mean with RTS (RS485 meaning) and RTS (UART flow control meaning), I post this link

What I need is the RS485 meaning.

Thanks

I can’t answer that. When used with an ordinary UART driver, the RTS and CTS are optional Request to Send and Clear to Send pins. When enabled, the UART will assert RTS and wait for CTS before it sends.

I am just using imagination here, but it seems that function can be enabled, and then used with other hardware to convert this to the direction control…but I don’t know enough about RS-485 to say what would be needed. The URL I gave above does have some schematics which I think are related to that topic. If you are interested in also using a GPIO pin, then I believe logically you could do this, but beware performance (latency in particular) may have a high standard deviation and cause problems at times. If you are running at slower speeds, then it is more likely latency variation won’t matter.

Hello
ok I will wait if another guest will reply to this topi. Yes, it’s better that the system (hw) handle this but also “driving” this pin before transmit operation could work (only be sure that the Tx data packet is trutly transmitted out of HW FIFO’s before deasserting).
So I will wait for other contributors

K.R.

hello f.ortolano,

Jetson Nano’s hardware is used a duplex UART instead of half duplex UART.
you may check this topic as see-also, Jetson Nano Half Duplex UART (For RS485) - #14 by JerryChang,
thanks

Hello JerryChang

ok but I wondering one thing: is RTS pin “physically” handable like a GPIO removing the pin from UART configuration and handling it like a simple GPIO? in this case I will handle the behaviour by myself using kernel setting of the value in the mosule. If yes, what is the GPIO associated?
Thanks

hello f.ortolano,

please check pinmux spreadsheets for reference,
you may refer to Uart flow control on Jetson Nano - #9 by JerryChang for an example to force the pin as low state.
thanks