I have two Sealevel USB-to-Serial adapters. They initially come up as /dev/ttyUSB1 and /dev/ttyUSB2 (another device briefly comes up as /dev/ttyUSB0 and then goes away). When these devices are disconnected and reconnected and my application keeps its handle to them open, they come back as /dev/ttyUSB0 and /dev/ttyUSB3.

What I need to do is check the return value of my read() and write() calls and close my port handle when they fail. Then I can call open again the next time I need to read/write. The problem, I think, is that if I don't close the handle quick enough, the device will still come back as a different ttyUSB* then it was originally.

So my question is, in my C user-mode application, can I programmatically determine the ttyUSB* based on a physical location. For example, based on any of the following information:

First Sealevel card:
hub 4-0:1.0: port 1
usb 4-1
ftdi_sio 4-1:1.0

2nd Sealevel card:
hub 4-0:1.0: port 2
usb 4-2
ftdi_sio 4-2:1.0

As you probably know, if you want to see a hierarchy of hardware connected to your computer, you can use linux’s sysfs virtual filesystem. Sometimes it’s hard to see where things go or come from. An easy way to see this is to use the udevmonitor utility. First, unplug both devices. Then, at a root shell, type:
(this should show you kernel events, udev events, and a nice collection of environment variables for each event). Now, plug in one device. Wait a bit. Now, remove it. Wait a bit. Plug in the other device. Etc.

The DEVPATH or PHYSDEVPATH variables show you what physical connection your device has. Those are actual subdirectories of /sys.

In addition to just learning this information, you can use it. If you create a udev rule, you might assign each ttyUSBx based on something distinguishable about your device (perhaps a serial number). Using usb device locations will probably work for simple setups, but is not recommended for production setups (because of USB’s daisy-chain nature). That’s one way to assign tty based on physical devices.

Thanks for the reply! That is more or less what I ended up doing.

I use opendir() to open up the following directories for the two different ports:
/sys/devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/
/sys/devices/pci0000:00/0000:00:1d.2/usb4/4-2/4-2:1.0/

Then, I use readdir() until I find a directory entry that starts with ttyUSB. That's how I figure out what "/dev/ttyUSB*" to use in my call to open().

I think it would be beneficial to move the logic of determining the tty out of your program and into udev rules.

Suppose you have two ftdi devices, a green one and an orange one. You can use udev rules to arrange the insertion and removal of the devices to trigger the creation of certain device nodes. For example, you can make it so the green one will always exist as “/dev/ttyUSB/green” and the orange one will always exist as “/dev/ttyUSB/orange” by matching distinguishable qualities of each device. Then, in your program, you don’t have to mess around with determining which is which, because you know that the “/dev/ttyUSB/green” will always be the character device for the green, and that “/dev/ttyUSB/orange” will always be the character device for the orange.

Of course in real life you might chose something besides their colors for the names (for example, the device on the other end). You might have it so “/dev/ttyUSB/bottom” and “/dev/ttyUSB/top” describe the two devices based on whether they are plugged into the bottom or top of your USB ports. This would remove some complexity from your program, and let it worry about what it needs to do.