0

I'm testing RS-232 communication between two devices(1: Red Hat Linux, 2: Windows)

I can check sending and receiving data. In Windows, it can be checked with a serial communication program, and in Linux, it is easy to check with a terminal. After making the same basic settings for RS-232 communication, I tried sending and receiving data.

If data is sent from the Linux device to the Windows device, I can check that it has been received in the Windows communication program. Conversely, if data is sent from the Windows device to the Linux device, it does not appear on the terminal despite doing cat /dev/ttySX.

The commands I entered to test RS232 data sending and receiving are as follows.

dmesg | grep ttyS

#output:
ttyS0 at MMIO 0xdf301000 (irq = 126, base_baud = 7812500) is XR17V35X
ttyS1 at MMIO 0xdf301400 (irq = 126, base_baud = 7812500) is XR17V35X
ttyS2 at MMIO 0xdf301800 (irq = 126, base_baud = 7812500) is XR17V35X --> real usage
ttyS3 at MMIO 0xdf301c00 (irq = 126, base_baud = 7812500) is XR17V35X

setserial /dev/ttyS2 uart 8250

# Output
ttyS0 UART:undefined Port:0x0000
ttyS1 UART:undefined Port:0x0000
ttyS2 UART:8250 Port:0x0000 ---> Why port is 0x0000?
ttyS3 UART:undefined Port:0x0000

stty -F /dev/ttyS2 115200 cs8 -cstopb -parenb

Open two terminal and execute following command each:

Terminal 1:

cat /dev/ttyS2" (or "cat < /dev/ttyS2")

Terminal 2:

echo -e -n \x2\x3\x1\x0\x0\x0\x0\x3 > /dev/ttyS2

The data sent from Terminal 2 is received well in the serial communication program of the Windows device, but the data sent from the Windows device does not appear on Terminal 1. However, when I did not say cat /dev/ttyS2, I only sent it from the Windows serial program, but when I command cat /dev/ttyS2, I also received a response.

Question: What if I want to display the data received on cat /dev/ttyS2? And what does Port 0x0000 mean?

Thank you for reading this.

Edgar Magallon
  • 4,820
Nam Seungwoo
  • 3

1 Answers1

0

What if I want to display the data received on cat /dev/ttyS2?

You may be using a tool that does not fit your purpose very well. Although cat is conceptually very simple, its implementation might not be simple at all.

cat may be designed to primarily operate with files on block devices, and so it may buffer its input & output. It may initially process any small amount of data that is readily available (in order to "sync up" with an input stream that is assumed to come from a block-oriented device), and when that data has been processed and cat is forced to wait for more data, it will wait for a larger chunk of data to arrive before processing it all at once, to provide for efficient filesystem input/output.

This question indicates that the GNU cat might use a buffer that is at least 128 KiB in size.

Other implementations of cat might be very different in their (non?)buffering behavior.

Instead of using two separate terminals and generic commands, you might use a single utility designed to work with serial ports specifically, such as minicom (can be found in RHEL standard package collection). If you want something simpler/more minimalist, the EPEL repository should have picocom (Github and description here).

These programs won't make any block-oriented assumptions, and will also "know" how to ensure that the PTY device of your terminal won't induce delays to incoming data by another layer of buffering.

And what does Port 0x0000 mean?

The original 8250 UARTs of the PC architecture were operated using port-mapped I/O, essentially using a separate address space for I/O ports with dedicated CPU instructions for using it. Since this used to be the norm for a long time, Linux tools like setserial just assume that every 8250-compatible UART lives in some port address.

However, your modern XR17V35X UART chip is backwards compatible to 8250, but designed to use memory-mapped I/O because PCIe bus doesn't really have a separate I/O address space any more, and on modern systems, memory-mapped I/O tends to be more efficient: instead of using legacy inp and out instructions to access the I/O address space, the UART's registers can be accessed with the same normal, highly-optimized CPU instructions that are used with memory.

When the message ttyS2 at MMIO 0xdf301800 ... is logged in dmesg, it indicates the physical/bus address to which the XR17V35X UART has been mapped. A memory-mapped UART will have no port address, so it would be more appropriate for setserial to say e.g. Port: n/a to indicate that the concept of a port address is not applicable to this particular UART, and/or display something like MMIO:0xdf301800 instead.

telcoM
  • 96,466