CTS RTS Pin enable

[blueengineer]

Hello, I want to establish RS485 communication using UART5 port with Raspberry Pi CM4. However, the transceiver I'm using (ISO3082) has DE (Driver Enable) and RE (Receiver Enable) pins that need to be set as high and low, and these pins are connected to GPIO14 (CTS5). I added the line

Code: Select all

dtoverlay=uart5,ctsrts

to the boot config, but when I check it with an oscilloscope, I don't see any changes on this pin. When I run code

Code: Select all

import serial

port = "/dev/ttyAMA1"  # UART5 portu
baud_rate = 9600

# Seri portu başlat
ser = serial.Serial(port, baud_rate)

while True:
    RTS_status = ser.getCTS()
    if RTS_status:
        print("ON")
    else:
        print("OFF")

in Python, I get output "OFF".

How can I make it work?

[PhilE]

To see if the overlay has been applied correctly and is being used by the kernel, what does "raspi-gpio get 12-15" show?

Note that with one of the latest kernels, enabling UART5 results in /dev/ttyAMA5 appearing, not /dev/ttyAMA1.

[blueengineer]

To see if the overlay has been applied correctly and is being used by the kernel, what does "raspi-gpio get 12-15" show?

Note that with one of the latest kernels, enabling UART5 results in /dev/ttyAMA5 appearing, not /dev/ttyAMA1.

raspi-gpio get 12-15
terminal output

Code: Select all

GPIO 12: level=1 fsel=3 alt=4 func=TXD5 pull=NONE
GPIO 13: level=1 fsel=3 alt=4 func=RXD5 pull=UP
GPIO 14: level=1 fsel=3 alt=4 func=CTS5 pull=UP
GPIO 15: level=0 fsel=3 alt=4 func=RTS5 pull=NONE

Kernel is probably latest version. It's 6.1.21-v8+
in which version of kernel shows ttyAMA5?

[PhilE]

> in which version of kernel shows ttyAMA5?

The patch appeared in 6.1.26, so it should be included in yours. "ls /dev/ttyAMA*" if you're in doubt. Note that you might get different results if the Device Tree (dtb) files weren't also updated.

[blueengineer]

> in which version of kernel shows ttyAMA5?

The patch appeared in 6.1.26, so it should be included in yours. "ls /dev/ttyAMA*" if you're in doubt. Note that you might get different results if the Device Tree (dtb) files weren't also updated.

I update the kernel now it is 6.1.29-v8+. But my problem isn't solved how i can enable the flow control of uart5?

[PhilE]

> how i can enable the flow control of uart5?

You've done enough to enable the flow control signals from the UART to appear on the 40-pin header, but:
1. The UART may not be configured to use them. RTS (strictly, nRTS) is driven low when the UART is ready to receive data. Similarly, it looks for low on its CTS (nCTS) signal before sending data. Try "sudo stty -F /dev/ttyAMA5 -a", and look for "crtscts" - "crtscts" means it's enabled, and "-crtscts" means it is disabled. Enable it with "sudo stty -F dev/ttyAMA5 crtscts", or using the Python serial module.

2. The UART may not be trying to use them - unless it has been opened, RTS should be high. Fortunately your test code does open the UART, so that shouldn't be the problem.

3. Your script is checking the level of the CTS signal, which is driven by the device at the other end. Unless the other device drives it low, your script will report "OFF". You can fake a device ready to receive data by running "raspi-gpio set 14 pd". Running your script after that should return "ON". Return things to normal with "raspi-gpio set 14 pu".

4. CTS and RTS are not the same as Driver Enable and Receive Enable. Are you sure they will do what you want?

[blueengineer]

> how i can enable the flow control of uart5?

You've done enough to enable the flow control signals from the UART to appear on the 40-pin header, but:
1. The UART may not be configured to use them. RTS (strictly, nRTS) is driven low when the UART is ready to receive data. Similarly, it looks for low on its CTS (nCTS) signal before sending data. Try "sudo stty -F /dev/ttyAMA5 -a", and look for "crtscts" - "crtscts" means it's enabled, and "-crtscts" means it is disabled. Enable it with "sudo stty -F dev/ttyAMA5 crtscts", or using the Python serial module.

2. The UART may not be trying to use them - unless it has been opened, RTS should be high. Fortunately your test code does open the UART, so that shouldn't be the problem.

3. Your script is checking the level of the CTS signal, which is driven by the device at the other end. Unless the other device drives it low, your script will report "OFF". You can fake a device ready to receive data by running "raspi-gpio set 14 pd". Running your script after that should return "ON". Return things to normal with "raspi-gpio set 14 pu".

4. CTS and RTS are not the same as Driver Enable and Receive Enable. Are you sure they will do what you want?

Yes, I know what it should do. When I send data via UART5 from any platform, I don't see any changes in the CTS pin. It remains constantly HIGH. Shouldn't it transition to LOW when I send data from raspberry?

[FTrevorGowen]

> how i can enable the flow control of uart5?

You've done enough to enable the flow control signals from the UART to appear on the 40-pin header, but:
1. The UART may not be configured to use them. RTS (strictly, nRTS) is driven low when the UART is ready to receive data. Similarly, it looks for low on its CTS (nCTS) signal before sending data. Try "sudo stty -F /dev/ttyAMA5 -a", and look for "crtscts" - "crtscts" means it's enabled, and "-crtscts" means it is disabled. Enable it with "sudo stty -F dev/ttyAMA5 crtscts", or using the Python serial module.

2. The UART may not be trying to use them - unless it has been opened, RTS should be high. Fortunately your test code does open the UART, so that shouldn't be the problem.

3. Your script is checking the level of the CTS signal, which is driven by the device at the other end. Unless the other device drives it low, your script will report "OFF". You can fake a device ready to receive data by running "raspi-gpio set 14 pd". Running your script after that should return "ON". Return things to normal with "raspi-gpio set 14 pu".

4. CTS and RTS are not the same as Driver Enable and Receive Enable. Are you sure they will do what you want?

Yes, I know what it should do. When I send data via UART5 from any platform, I don't see any changes in the CTS pin. It remains constantly HIGH. Shouldn't it transition to LOW when I send data?

IIRC CTS may be an input (from the RTS of the "other" device) FWIW, some (ancient**) notes of mine are here: https://www.cpmspectrepi.uk/rs232/rs232.htm
depending upon which device is equivalent to a "DTE" or "DCE" etc.
Trev.
** Originally an internal "web page" at my place of work pre- (public) WWW days.

[6by9]

IIRC CTS may be an input (from the RTS of the "other" device) FWIW, some (ancient**) notes of mine are here: https://www.cpmspectrepi.uk/rs232/rs232.htm
depending upon which device is equivalent to a "DTE" or "DCE" etc.
Trev.
** Originally an internal "web page" at my place of work pre- (public) WWW days.

Correct - For hardware flow control RTS (Ready To Send) is the output from the host, and CTS (Clear To Send) is returned by the receiving device to confirm that you can transmit.
(There are similar signals for the host to signal to the peripheral that it isn't ready to receive data - Data Terminal Ready (DTR) and Data Set Ready (DSR) by the looks of it).

For 2 wire RS485, RTS is normally connected to DE and nRE on the RS485 transceiver, and the host will assert RTS (and hence enable DE) when it wants to transmit. Once finished transmitting it drops RTS to disable the transmitter and enable the receiver. (4 wire RS485 normally leaves the receiver always active). CTS is not used.

Usage from Linux is documented in the kernel docs - https://www.kernel.org/doc/html/latest/ ... rs485.html

[blueengineer]

> how i can enable the flow control of uart5?

You've done enough to enable the flow control signals from the UART to appear on the 40-pin header, but:
1. The UART may not be configured to use them. RTS (strictly, nRTS) is driven low when the UART is ready to receive data. Similarly, it looks for low on its CTS (nCTS) signal before sending data. Try "sudo stty -F /dev/ttyAMA5 -a", and look for "crtscts" - "crtscts" means it's enabled, and "-crtscts" means it is disabled. Enable it with "sudo stty -F dev/ttyAMA5 crtscts", or using the Python serial module.

2. The UART may not be trying to use them - unless it has been opened, RTS should be high. Fortunately your test code does open the UART, so that shouldn't be the problem.

3. Your script is checking the level of the CTS signal, which is driven by the device at the other end. Unless the other device drives it low, your script will report "OFF". You can fake a device ready to receive data by running "raspi-gpio set 14 pd". Running your script after that should return "ON". Return things to normal with "raspi-gpio set 14 pu".

4. CTS and RTS are not the same as Driver Enable and Receive Enable. Are you sure they will do what you want?

Yes, I know what it should do. When I send data via UART5 from any platform, I don't see any changes in the CTS pin. It remains constantly HIGH. Shouldn't it transition to LOW when I send data?

IIRC CTS may be an input (from the RTS of the "other" device) FWIW, some (ancient**) notes of mine are here: https://www.cpmspectrepi.uk/rs232/rs232.htm
depending upon which device is equivalent to a "DTE" or "DCE" etc.
Trev.
** Originally an internal "web page" at my place of work pre- (public) WWW days.

Thank you for your response. I believe I couldn't fully explain my problem. I have a transceiver (ISO3082) which operates in half-duplex mode. When I want to send data from Raspberry Pi, I need to set the DE/RE' pins to HIGH, and when I want to receive data, I need to set them to LOW. The data flow will be controlled through Node-RED. I can achieve this data flow by manually setting the pin states, but I need to automate it. I thought CTS pin might be suitable for this, but it didn't work. How can I accomplish this through Config.txt .

[blueengineer]

IIRC CTS may be an input (from the RTS of the "other" device) FWIW, some (ancient**) notes of mine are here: https://www.cpmspectrepi.uk/rs232/rs232.htm
depending upon which device is equivalent to a "DTE" or "DCE" etc.
Trev.
** Originally an internal "web page" at my place of work pre- (public) WWW days.

Correct - For hardware flow control RTS (Ready To Send) is the output from the host, and CTS (Clear To Send) is returned by the receiving device to confirm that you can transmit.
(There are similar signals for the host to signal to the peripheral that it isn't ready to receive data - Data Terminal Ready (DTR) and Data Set Ready (DSR) by the looks of it).

For 2 wire RS485, RTS is normally connected to DE and nRE on the RS485 transceiver, and the host will assert RTS (and hence enable DE) when it wants to transmit. Once finished transmitting it drops RTS to disable the transmitter and enable the receiver. (4 wire RS485 normally leaves the receiver always active). CTS is not used.

Usage from Linux is documented in the kernel docs - https://www.kernel.org/doc/html/latest/ ... rs485.html

Thank you for your support. That's what I wanted to learn.