A2CLOUD: better means of identifying USB port than sequence of insertion for non-pi computers

[knghtbrd]

From @IvanExpert on October 25, 2015 21:58

Currently, Raspberry Pi's can have their physical USB ports identified and named "ttyUSBupper" and "ttyUSBlower" by UDEV rules, making it easy to connect the right cable to the right port in all cases.

Since non-Pi computers may have any configuration of USB ports and hubs, the behavior is to create "ttyUSBupper" being an alias to the first item inserted, and "ttyUSBlower" being the second item inserted. If they're both present at boot time, they'll be assigned randomly. I don't know if there's any better solution to this, but it seems inelegant.

Copied from original issue: RasppleII/a2server#23

[knghtbrd]

I consider the current convoluted behavior on the Pi to be a bug actually. ;)

[knghtbrd]

From @IvanExpert on October 26, 2015 13:42

To the contrary, I think describing exactly what physical ports to attach to is the least convoluted available solution, at least on a 4-port Pi, where a USB hub can go on one of the unused two right-hand ports. (I'll concede it's a bit more complicated if you are plugging the serial adapters into a hub, as you would usually need to with a 2-port Pi.)

[knghtbrd]

I tried plugging things into several places and couldn't get things
to behave. I couldn't even get ADTPro to give me a single port
showing up in its dropdown. It drove me nuts.

Either way, it doesn't scale beyond the Pi, nor does it work for
other ARM-based SBCs (including some that can run Raspbian.)
Something more robust is needed all around. As soon as I figure out
what that is, I'll propose something. :P

Joseph

[knghtbrd]

From @IvanExpert on October 27, 2015 0:11

ADTPro showing no ports in its dropdown is usually a symptom of librxtx not doing what it's supposed to. I've seen a fair bit of that sort of thing and it's irritating. You might want to check out the customized adtpro.sh script installed by A2CLOUD to see how I've coaxed it into being.

Can't argue with you about not scaling beyond the Pi, hence my creating the issue. Good luck coming up with something brilliant.

[knghtbrd]

One thing I have discovered (Linux-specific) is that /sys/class/tty contains directories describing every known TTY device on the system, buy that all of the virtual consoles, etc. lack device/driver. If I iterate over these, I can identify the available serial devices without opening them.

That's a linuxism, but I'm presently having trouble using ioctl() with TIOCGSERIAL from Python.

[knghtbrd]

Duplicate of #27

Well perhaps the other way around actually, but this issue proposes a problem. That one proposes a solution accepted in principle, but whose implementation may or may not require further consideration.