How to find which serial port is in use?
The Question: I plugged in a device (i.e. GSM modem) through a serial port (a.k.a. RS-232), and I need to see with which file in /dev/ filesystem this device was tied up, to be able to communicate with it. Unfortunately there is no newly created file in /dev/ nor can be seen anything in dmesg output. So this seems to be a hard question. Background: I had never worked with a serial device, so yesterday, when there appeared a need, I tried to Google it but couldn’t find anything helpful. I spent a few hours in seek, and I want to share a found answer as it could be helpful for someone.
I like using those bits to detect a device — I’ll probably use that, although I’ve many devices that only use the Tx/Rx pins, I could probably hack them to hold the CTS line high for that.
2 Answers 2
Unfortunately serial ports are non-PlugNPlay, so kernel doesn’t know which device was plugged in. After reading a HowTo tutorial I’ve got the working idea.
The /dev/ directory of unix like OSes contains files named as ttySn (with n being a number). Most of them doesn’t correspond to existing devices. To find which ones do, issue a command:
$ dmesg | grep ttyS [ 0.872181] 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 0.892626] 00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A [ 0.915797] 0000:01:01.0: ttyS4 at I/O 0x9800 (irq = 19) is a ST16650V2 [ 0.936942] 0000:01:01.1: ttyS5 at I/O 0x9c00 (irq = 18) is a ST16650V2 Above is an example output of my PC. You can see the initialization of a few serial ports:
ttyS0 , ttyS1 , ttyS4 , ttyS5 .
One of them is going to have a positive voltage upon a device plugged in. So by comparing the content of the file /proc/tty/driver/serial with and without the device plugged in we can easily find the ttyS related to our device. So, now do:
$ sudo cat /proc/tty/driver/serial> /tmp/1 $ sudo cat /proc/tty/driver/serial> /tmp/2 Next check the difference between the two files. Below is an output of my PC:
$ diff /tmp/1 /tmp/2 2c2 < 0: uart:16550A port:000003F8 irq:4 tx:6 rx:0 --- >0: uart:16550A port:000003F8 irq:4 tx:6 rx:0 CTS|DSR By comparing the three numbers with the dmesg output we can determine which one is the port:
[ 0.872181] 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Hence, our device is /dev/ttyS0 , mission accomplished!
@user3019105 sorry, I’ve never faced such issue. From what I understand, dmesg should have a message about assigning irq to a serial device. And if it didn’t, I’d assume some hardware problem. That’s just an assumption, and might be wrong, but if I’d debug such a problem, I’d start research with the idea in mind that serial port should’ve been initialized.
Since I move from machine to machine I have defined an alias to show me the serial ports on this machine. It works on Ubuntu family systems with systemd. alias ports=’udevadm info —export-db |grep -i «^n: ttyu»‘
You can also use setserial to get and set serial port information, in addition to dmesg .
setserial
# install it sudo apt update sudo apt install setserial # Display (and sort) serial information for all /dev/ttyS* devices setserial -g /dev/ttyS* | sort -V # Display (and sort) serial information for all /dev/ttyUSB* devices setserial -g /dev/ttyUSB* | sort -V # To see extra info. such as the baud rate too, add `-G`: setserial -g -G /dev/ttyS* | sort -V setserial -g -G /dev/ttyUSB* | sort -V Sample run and output. Notice that /dev/ttyS4 is the only port that appears to be alive and not «unknown» (whatever that means). (This /dev/ttyS4 device also shows up in the Arduino IDE even though it’s not an Arduino and I don’t know what it is.):
$ setserial -g -G /dev/ttyS* | sort -V /dev/ttyS0 uart unknown port 0x03f8 irq 4 baud_base 115200 spd_normal skip_test /dev/ttyS1 uart unknown port 0x02f8 irq 3 baud_base 115200 spd_normal skip_test /dev/ttyS2 uart unknown port 0x03e8 irq 4 baud_base 115200 spd_normal skip_test /dev/ttyS3 uart unknown port 0x02e8 irq 3 baud_base 115200 spd_normal /dev/ttyS4 uart 16550A port 0x3060 irq 19 baud_base 115200 spd_normal skip_test /dev/ttyS5 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS6 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS7 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS8 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS9 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS10 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS11 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS12 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS13 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS14 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS15 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS16 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS17 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS18 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS19 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS20 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS21 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS22 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS23 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS24 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS25 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS26 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS27 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS28 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS29 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS30 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal /dev/ttyS31 uart unknown port 0x0000 irq 0 baud_base 0 spd_normal dmesg
Use dmesg to also see some of this information:
# Show UART information, incl. baudrate, for /dev/ttyS* devices. dmesg | grep ttyS # Show UART information, incl. baudrate, for /dev/ttyUSB* devices. dmesg | grep ttyUSB $ dmesg | grep ttyS [ 1.624447] 0000:00:16.3: ttyS4 at I/O 0x3060 (irq = 19, base_baud = 115200) is a 16550A Even better, watch the dmesg kernel ring buffer output live with the -w option:
Now, unplug your USB device you’re trying to identify and plug it back in to see which device it is, based on the messages that show up in the dmesg output, live.
How do I know which serial port to use on Linux?
I’m going to be writing a program in C which is going to open a connection over serial port, and «listen» for incoming commands, then it will take some action and report back a status. The connection is going to be over RS232 (Serial port) and I’m trying to understand how to know which port to open. When using windows, if I hook up my usb-serial device I see «Prolific USB-to-Serial Comm Port (COM4)» show up in the device manager. but on the Linux side I don’t see any changes in the /sys/class/tty or /dev area, I see ttyS0 through ttyS7 present all the time (I’m assuming the S stands for serial based on what I’ve read). So how do I know which one to connect to? EDIT
While I’m developing this on a OpenSUSE 12.1 box (3.1 kernel), the final program will be run on uCLinux on a board running a 2.4Linux kernel, so I’m looking for pure C solutions which will work on older kernels FYI: the /sys file system as noted in the answer to this post didn’t exist until the 2.6 kernel and my constraints force me to stick to things available in the 2.4 kernel.
Chances are that your USB serial port adapter will show up as /dev/ttyUSB0 . Also check this question if you need a way to enumerate the serial ports.
@PhilippeGauthier — That would be very unfortunate considering I won’t know if the user is going to use a usb->serial cable, or a straight serial cable. 🙁
@goldenparrot — The target platform for this program will most likely not have python support. (uCLinux)
@PhilippeGauthier — Checked out that link, it’s a good idea, but using /sys file system which I need to stay away from. /sys didn’t show up until 2.6 and since I need to keep compatibility in mind with our 2.4 system, I can’t use that. Thanks though!
C++ linux detect all serial ports
Is there a good way of detecting all connected devices connected on serial ports on linux? Im programming in C++ but other examples are welcome as well. You can just try to open every port and when it succeeds you add it to the list of ports but this seems not a really good solution. You could go into the dev directors and since my serial port is a USB port I can check which ttyUSB.. files have been made. But this doesn’t work for non USB serial ports since files for tty0 up to tty63 are always in this directory. My example:
std::string port; int fd std::vector> list; for(int i = 0; i < 256; ++i) < port.clear(); port.append("/dev/ttyUSB"); port.append(std::to_string(i)); fd = open(port.c_str(), O_RDWR | O_NOCTTY | O_DELAY); if(fd != -1) < list.push_back(port); >> This gives me the feel of an XY question, where your actual problem is X, and you think the solution is Y, so you ask for Y. Why do you want to know about serial ports on the system?
On 1 of the ports a zigbee device is connected. Since I want to make it user friendly I want to list all possibilities so that the user can pick. Normally if you plug in your zigbee device you should get exactly one port number returned to you. @Hasturkun In my case since my serial device uses a USB connection it is named ttyUSB0.
in theory you could do the same for /dev/ttyX if you want normal serial ports. But again not the best way to go.
3 Answers 3
The standard way of enumerating devices in Linux is to browse the /sys filesystem. In this case, you can to the following:
- Enumerate all files in /sys/class/tty
- For each directory /sys/class/tty/foo , check if /sys/class/tty/foo/device exists using lstat() .
- If it does not exist then you are dealing with some kind of virtual tty device (virtual console port, ptmx, etc. ) and you can discard it.
- If it exists then retain serial port foo .
You should be left with a list of actual serial ports.
I get 32 devices via this mechanism. 2 are valid. You need to check that it’s not pointing at serial8250 , which is actually just the driver
On several of my systems, I have real valid serial ports where the device symlink points to serial8250 . I’m not sure why you get so many invalid ones.
the 32 comes from the kernel config value CONFIG_SERIAL_8250_RUNTIME_UARTS , I presume it’s to support more than the default 32 (this is an x64 3.2 kernel).
If I just chek sys/class/tty/ttyS.. then I find a device folder in all of them. So that is probably how Petesh gets to 32 since ttyS goes from 0 to 31.
@Lotharyx You can use udevadm info /sys/class/tty/
Given that a number of years have passed since this was answered I am adding this answer. This answer works for later versions of linux. It also uses the new std::filesystem introduced in c++17. std::filesystem is available in earlier versions of c++ either through boost or in the namespace std::experimental::filesystem (use #include ). If using boost you must include compiled component system
This example also works out the where the symlink points to and returns it’s canonical name.
#include #include #include #include using std::cout; namespace fs = boost::filesystem; std::vector get_available_ports() < std::vectorport_names; fs::path p("/dev/serial/by-id"); try < if (!exists(p)) < throw std::runtime_error(p.generic_string() + " does not exist"); >else < for (fs::directory_entry &de : fs::directory_iterator(p)) < if (is_symlink(de.symlink_status())) < fs::path symlink_points_at = read_symlink(de); fs::path canonical_path = fs::canonical(symlink_points_at, p); port_names.push_back(canonical_path.generic_string()); >> > > catch (const fs::filesystem_error &ex) < cout std::sort(port_names.begin(), port_names.end()); return port_names; >