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.

[stevend]

Did you succeed in getting the RS-485 mode working?

(Couldn't make it work a month or two ago with both 5.15 and an early 6.x kernel, but there's been a significant kernel update since that I have yet to try).

[blueengineer]

Did you succeed in getting the RS-485 mode working?

(Couldn't make it work a month or two ago with both 5.15 and an early 6.x kernel, but there's been a significant kernel update since that I have yet to try).

Yes but not with kernel. There is a simple solution. You can change the settings on minicom. If you have any questions about how I can help you can write.

[stevend]

Yes but not with kernel. There is a simple solution. You can change the settings on minicom. If you have any questions about how I can help you can write.

Good tip, thanks.
I got things working with minicom to prove that the capability was present on my hardware and OS version.
Minicom also gives me a working code sample (which looked pretty much identical to my own code!).
However......
1. As soon as I run my own code, RTS stops working - its at a fixed level (high - should go low to enable the buffer).
2. Once I've run my own code, minicom stops controlling RTS - the line just remains high.

In all cases serial data is sent out; it's just RTS that doesn't behave as expected.

Immediately after boot, the GPIO pins are configured as CTS and RTS as expected.

Found - I was changing the mode of RTS elsewhere in the code - legacy of early testing!

[FTrevorGowen]

Yes but not with kernel. There is a simple solution. You can change the settings on minicom. If you have any questions about how I can help you can write.

Good tip, thanks.
I got things working with minicom to prove that the capability was present on my hardware and OS version.
Minicom also gives me a working code sample (which looked pretty much identical to my own code!).
However......
1. As soon as I run my own code, RTS stops working - its at a fixed level (high - should go low to enable the buffer).
2. Once I've run my own code, minicom stops controlling RTS - the line just remains high.

In all cases serial data is sent out; it's just RTS that doesn't behave as expected.

Immediately after boot, the GPIO pins are configured as CTS and RTS as expected.
After running either program, RTS is configured as a simple output - looks like minicom (and, by inference, my program) just stops driving it.

OOC what happens if you try GtkTerm instead (which IMHO is easier to configure and provides useful additional tools/diagnostic display etc., especially when dealing with "unusual" serial data streams eg. https://www.cpmspectrepi.uk/raspberry_p ... 000zc.html )
Trev.

[6by9]

I've just tried following the kernel docs for RS485 with a logic analyser connected to TXD and RTS. I was using UART3 on a Pi4, so GPIO 4 for TXD, and GPIO 7 for RTS using "dtoverlay=uart3,ctsrts" in /boot/config.txt.

Code: Select all

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>

#include <linux/serial.h>

/* Include definition for RS485 ioctls: TIOCGRS485 and TIOCSRS485 */
#include <sys/ioctl.h>

int main(void)
{
  int ret;

  /* Open your specific device (e.g., /dev/mydevice): */
  int fd = open ("/dev/ttyAMA1", O_RDWR);
  if (fd < 0) {
        /* Error handling. See errno. */
  }

  struct serial_rs485 rs485conf = {0};

  /* Enable RS485 mode: */
  rs485conf.flags |= SER_RS485_ENABLED;

  /* Set logical level for RTS pin equal to 1 when sending: */
  rs485conf.flags |= SER_RS485_RTS_ON_SEND;
  /* or, set logical level for RTS pin equal to 0 when sending: */
  //rs485conf.flags &= ~(SER_RS485_RTS_ON_SEND);

  /* Set logical level for RTS pin equal to 1 after sending: */
  //rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
  /* or, set logical level for RTS pin equal to 0 after sending: */
  rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);

  /* Set rts delay before send, if needed: */
  //rs485conf.delay_rts_before_send = ...;
  ret = ioctl (fd, TIOCSRS485, &rs485conf);

  if (ret < 0) {
        /* Error handling. See errno. */
     printf("ioctl failed %d, errno %d\n", ret, errno);
  }

  /* Use read() and write() syscalls here... */
  write(fd, "FOO BAR", 7);

  /* Close the device when finished: */
  if (close (fd) < 0) {
        /* Error handling. See errno. */
  }

  return 0;
}

Makefile

Code: Select all

CROSS_COMPILE ?=

CC      := $(CROSS_COMPILE)gcc
CFLAGS  ?= -O2 -W -Wall -std=gnu99
LDFLAGS ?=
LIBS    := -lrt 

%.o : %.c
        $(CC) $(CFLAGS) -g -c -o $@ $<

all: rs485

rs485: rs485.o
        $(CC) $(LDFLAGS) -o $@ $^ $(LIBS)

clean:
        -rm -f *.o
        -rm -f rs485

Run that and I get the following trace

RS485.png (176.48 KiB) Viewed 2060 times

With the exception of the 0.5us blip after the message, that is exactly what I'd expect. If RTS is connected to DE and nRE on a MAX3485 or similar, the transmitter will be enabled whilst there is data to send, and then drops back to receive mode.

The RS485 setting appears to be retained after the device is closed, so running "cat /boot/config.txt > /dev/ttyAMA1" afterwards also sends the data in exactly the way I'd expect (RTS taken high whilst there is data being actively sent).

The blip looks odd, but would need a fair amount of studying the driver to work out what is going on.
If I "cat Makefile" to ttyAMA1 then I get a couple of blips during the message, but they are always at byte boundaries. RS485 should have bias resistors on the line, so all drivers being disabled should result in a defined state that is the same as the stop state. It should therefore be harmless. At a guess the "cat" is being slow at refilling the FIFO, so the driver sees nothing more to send and drops RTS.

[stevend]

Just this minute found it, thanks - I was changing the mode of RTS elsewhere in the code - legacy of early testing!

Looks as if the RS-485 part of the driver checks that the RTS pin is in mode 4.

[6by9]

Just this minute found it, thanks - I was changing the mode of RTS elsewhere in the code - legacy of early testing!

Looks as if the RS-485 part of the driver checks that the RTS pin is in mode 4.

The GPIO needs to be set to the relevant alt function for RTS. It is then controlled through the RTS fields of the UART block, not as a GPIO.
Configuration of that pin-muxing is done via device tree, not the driver.

[stevend]

The GPIO needs to be set to the relevant alt function for RTS. It is then controlled through the RTS fields of the UART block, not as a GPIO.
Configuration of that pin-muxing is done via device tree, not the driver.

Yes indeed, although it turns out that there are two ways to achieve the desired result:
1. Adding ctsrts=on to the uart definition in config.txt is no doubt the "official" way (i.e. "dtoverlay=uart4,ctsrts=on").
However I need to use CTS as generic I/O, and modifying the relevant pin in my program achieves that.

2. Just using "dtoverlay=uart4" in config.txt, then setting the RTS pin to alt-mode 4 in code (or, I imagine, also via one of the command line utilities).

I've gone for the second option to be absolutely certain there's no "hidden" assertion in the settings that there's a CTS function associated with the UART.

Based on quick tests, either method of configuration appears to work.

[blueengineer]

The GPIO needs to be set to the relevant alt function for RTS. It is then controlled through the RTS fields of the UART block, not as a GPIO.
Configuration of that pin-muxing is done via device tree, not the driver.

Yes indeed, although it turns out that there are two ways to achieve the desired result:
1. Adding ctsrts=on to the uart definition in config.txt is no doubt the "official" way (i.e. "dtoverlay=uart4,ctsrts=on").
However I need to use CTS as generic I/O, and modifying the relevant pin in my program achieves that.

2. Just using "dtoverlay=uart4" in config.txt, then setting the RTS pin to alt-mode 4 in code (or, I imagine, also via one of the command line utilities).

I've gone for the second option to be absolutely certain there's no "hidden" assertion in the settings that there's a CTS function associated with the UART.

Based on quick tests, either method of configuration appears to work.

"dtoverlay=uart4,ctsrts" if you add this to config.txt the ctr and rts pins are ready to use .

You can enable hardware flow control in this of minicom. it might be work i think.

Ekran görüntüsü 2023-06-08 100931.png (28.83 KiB) Viewed 1953 times

[6by9]

I wasn't expecting minicom to have RS485 settings, but you're right that it does.
Checking the source, it is using exactly the same ioctl call as I used above - https://salsa.debian.org/minicom-team/m ... ep1.c#L664

You can configure the port for rs485 mode from devicetree.
See the binding and implementation. Just adding the boolean "linux,rs485-enabled-at-boot-time" is likely to be sufficient for the basic case.

[stevend]

I wasn't expecting minicom to have RS485 settings, but you're right that it does.

Nor was I (even the minicom site doesn't mention it in a reasonably obvious manner) - so thanks to @blueengineer for pointing it out. Meant that I went from looking in the wrong place to looking in the right place, after which I got things working quite quickly!

Checking the source, it is using exactly the same ioctl call as I used above - https://salsa.debian.org/minicom-team/m ... ep1.c#L664

I think all RS-485 setup code has its roots in that one example in the manual! Certainly my own code, and every other example I've found, looks very similar.

You can configure the port for rs485 mode from devicetree.
See the binding and implementation. Just adding the boolean "linux,rs485-enabled-at-boot-time" is likely to be sufficient for the basic case.

Potentially useful option (could the option be added to the README in the dtoverlay directory?). Unfortunately I need to be able to change the serial port mode from a user-friendly menu, so am reckoning to force RTS disabled on boot, then configure the port as required in my own code.