search

RasppleII / a2server

AppleTalk server for Apple II computers
Other
31 stars 8 forks source link

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

Closed IvanExpert closed 8 years ago

IvanExpert commented 8 years ago

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 commented 8 years ago

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

IvanExpert commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

This issue was moved to RasppleII/a2cloud#12

knghtbrd commented 8 years ago

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 #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: https://github.com/RasppleII/a2server/issues/23#issuecomment-151320245