Add error message for port (-p port_name) that is not in filtered port list (-P)

[PropGit]

Add error response when port requested (via ... -p <port_name>) that is not in the supported/filtered list (retrieved via ... -P).

For example, on a Mac, if the command-line is this:
proploader -p /dev/tty.usbserial-AH016W5L my_application
response could be, a fatal error... the port is not opened and the following message is emitted:
Error: can not open port /dev/tty.usbserial-AH016W5L

This need was brought up in Issue #31 because the user was specifying a dev/tty.* port on a Mac instead of a dev/cu.* port, causing intermittent failures. The -P option response only includes the dev/cu.* ports and not the dev/tty.* ports.

[dbetz]

I don't think you want me to do the equivalent of "proploader -P" whenever I do a serial load do you? I think it would currently reset any Propeller that is connected. Also, filtering out anything but "cu.xxx" for the Mac might be a bad idea because there could be devices people could connect that would have different names. I'm not sure about that but it could happen. I could see putting in a warning if you specify something that doesn't match the expected port name prefix.

[dbetz]

FYI, here is a description of the difference between the tty. and cu. devices:

The idea is to supplement software in sharing a line between incoming and outgoing calls. The callin device (typically /dev/tty*) is used for incoming traffic. Any process trying to open it blocks within the open() call as long as DCD is not asserted by hardware (i.e. as long as the modem doesn't have a carrier). During this, the callout device (typically /dev/cu* -- cu stands for "calling unit") can be freely used. Opening /dev/cu* doesn't require DCD to be asserted and succeeds immediately. Once succeeded, the blocked open() on the callin device will be suspended, and cannot even complete when DCD is raised, until the cu device is closed again.

That way, you can have a getty listening on /dev/tty*, and can still use /dev/cu* without restrictions.

[PropGit]

The first question to answer is: are /dev/tty* ports already filtered out of -P operations by PropLoader on Macs (and not on Linux)? Issue #31 led me to believe that's the case, and the tty definitely caused a problem on his Mac.

If the answer is "yes", then: During a -p download request, internally in PropLoader it'd be fine to do the equivalent of a -P operation and then check the requested -p against the new list to make sure it exists. This way, if a port is requested that doesn't appear in the list we normally provide by -P (because it either doesn't currently exist or because we've filtered it out, for example) then we can prevent the problems that occurred in Issue #31. The -P operation won't reset the Propeller(s) because PropLoader is not scanning for Propellers on serial ports... it's just listing what ports are currently available on the system.

If the answer is "no," then: Should we start filtering out /dev/tty* ports on the Mac? Do you know why the customer experienced flaky problems with requesting /dev/tty* instead of /dev/cu* on his Mac? Maybe this just boils down to a documentation and support issue?

[dbetz]

Yes, the only ports that are listed are ones that match "/dev/cu.".
I think the issue is that I'm pretty sure I've seen a serial adapter that ended up being named something other than "/dev/cu." and I wanted to make sure it was possible to select that explicitly even though -P wouldn't find it. Also, I think propeller-load does try to identify Propeller chips. Shouldn't proploader do the same?

[PropGit]

Right, propeller-load does that, but we never did so with proploader. We don't have a use case where we want that functionality in proploader yet. Keep it as it is now.

I wonder why we chose to filter out everything but /dev/cu.* on Mac? I can't remember doing that. Maybe it'd be better to just remove any /dev/tty.* from the list (on Mac only).

[dbetz]

I did it because propeller-load does it as well on the Mac. Much of the code in proploader is taken directly from propeller-load.

[dbetz]

Where do we stand with this? Do we really want to restrict the device names to /dev/cu.* or should we allow other names as well? I can't say that I have an example of a serial port with a different name but have a nagging feeling that I saw one at one time. Maybe we should just issue a warning if the user tries to specify /dev/tty.* since we know that won't work.

[zfi]

There are more serial port names in the nix world than /dev/cu. Granted that the most common type of serial port is a USB device providing a serial service interface. But it's not the only game in town.

http://www.tldp.org/HOWTO/Serial-HOWTO-10.html

[dbetz]

The code for Linux is using /dev/ttyUSB*. It's only the Mac that uses /dev/cu.. I know that eliminates all real serial ports but if you include all of /dev/tty you get zillions of ports most of which are not really there. I have never understood why Linux includes so many /dev/tty* ports.

[PropGit]

@dbetz and I agree now that on Mac only, since we're already filtering out the /dev/tty* ports from what PropLoader returns, that it should provide an error message if the user attempts to give it a /dev/tty* port to operate with. That means it will accept any other port names (valid or otherwise) on the Mac and a later error will be thrown if the given port doesn't exist or fails to open for any other reason.

This solution should quickly lead the user, who mistakenly gives it a /dev/tty* port name, to the correct solution, instead of misleading them and delivering flaky results like what happened to the user that reported this problem.

[dbetz]

Actually, I have another idea. Would it be bad to accept /dev/tty.xxx but translate it to /dev/cu.xxx?

[PropGit]

Yes, that would be fine as long as it's only done on Macs and as long as other potential errors (like /dev/cu.xxx doesn't exist or can't be opened) still apply properly after the translation.

[dbetz]

Mac only of course. The only problem I can see is that the error messages might mention the translated name not the original name that the user specified. Maybe I should add an information message saying something like "using /dev/cu.xxx instead of /dev/tty.xxx".

[PropGit]

Yes, I like the added informational message, "using /dev/cu.xxx instead of /dev/tty.xxx"