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

[IvanExpert]

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.

[knghtbrd]

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

[IvanExpert]

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

[IvanExpert]

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]

This issue was moved to RasppleII/a2cloud#12

[knghtbrd]

My thinking process is:

1. Udev comes with rules for /dev/serial/ that supposedly create
   unique and reliable device identification for serial ports. I
   know this includes (and was created for) USB devices. I know also
   that I don't see a /dev/serial/ entry for /dev/ttyAMA0 despite
   the fact that it clearly exists in /dev. I couldn't guess whether
   other serial devices that tend not to move around show up there,
   such as the good ol' 16550-based /dev/ttyS<#>. If ttyAMA0
   ought to be there and isn't simply because the rules don't know to
   create it, this bug should be fixed. Otherwise, we can work
   around it because we know where it comes from.
2. It is easy enough to find out if a serial port is currently in use
   by another program. We can also tell if we've designated a given
   port for ADTPro/VSDRIVE, Apple II Pi, or for serial console.
3. We can present the user with a list of detected serial ports along
   with information that may help identify them. USB serial devices
   should have vendor/product IDs (even if it's just info like
   "Prolific" and "FTDI", that helps), ttyAMA<#> devices are
   something like "ARM integrated (GPIO) UART", ttyS<#> devices are
   "PC serial port (COM<#+1>)", etc. So we display the device, what
   it is if we know, if it's currently in use, and what we're using
   it for if we're using it.
4. From License terms unclear #3, we can allow the user to select a port, configure its
   settings, test the connection using one of a couple of different
   mechanisms, and assign a port to be used for whatever supported
   purpose they want, etc. Of course if the port has a unique
   designator in /dev/serial, we use THAT, which means I need to come
   up with a non-confusing way to display both or risk someone
   getting confused looking at the ADTPro config file or something.

Granted, this is more complex than "connect it to the top USB port",
but also doesn't depend on us knowing anything about their USB
topology, or even that their serial ports are USB devices.

It does introduce the need to help them figure out what a given
serial port is connected to and whether or not it works right. But
then, that's highly desirable IMO anyway. Ways I can think of to
test a serial port include a loopback connector, blinky serial LEDs
(on the USB adapter or inline with your serial cable), or via a very
short BASIC command/program on the Apple.

If the user selects they want to test the port, we can give them a
prompt to say when they're ready, or ask for setup instructions.
When they are ready to test, we'll send something short over the
serial port and listen for the same in response. If using a loopback
adapter, we'll get it immediately. Otherwise we'll get it when the
Apple sends it to us. Q to quit listening on the Pi if something
goes wrong.

The Pi will send then listen. It's possible you could make the Apple
listen then send, but I figured it'd do well enough to have the Apple
blindly send. If flow control is wrong, it won't go through either
way.

Anyway, that's where this is going in my head. I figure typing a
line or two into the Apple is within most Apple users' capabilities,
and if it's not much more complex a command than the ADTPro bootstrap
settings, it's not unreasonable to do it that way.

I'm going to follow your lead @IvanExpert in recommending known
serial devices that work (conveniently all with DE-9 connectors) and
suggest that some specific DE-9 loopback devices and blinkenlights
adapters might be useful. My general recommendation to someone
setting this stuff up would be to plug the loopback into the port
they want to use for and test ports till they find the right
one. Then connect it to the Apple and run the test that way to test
your cable connection.

If I could've easily done that when I was setting up A2CLOUD/ADTPro
the first time (Pi 2, USB hub, FTDI adapter, etc...) ;)

Joseph

On Mon, Oct 26, 2015 at 05:11:29PM -0700, IvanExpert wrote:

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.

---

Reply to this email directly or view it on GitHub:
#23 (comment)