[PD] comport port numbers :: bash trick

[Martin Peach]

Hans-Christoph Steiner wrote:
>
> On Sep 24, 2006, at 6:52 PM, Martin Peach wrote:
>
>> Hans-Christoph Steiner wrote:
>>>
>>> On Sep 24, 2006, at 5:49 PM, Martin Peach wrote:
>>>
>>>> Martin Peach wrote:
>>>>> Martin Peach wrote:
>>>>>> Hans-Christoph Steiner wrote:
>>>>>>>
>>>>>>> On the latest version of [comport], the [info( message should 
>>>>>>> print out a similar output to the Pd window.
>>>>>> Don't try it on Windows though, you'll crash pd.
>>>>>>    for(i=1; i<COMPORT_MAX; i++)
>>>>>>    {
>>>>>>        /* TODO: this should actually probe ports */
>>>>>>        post("\t%d - COM%s", i, i);
>>>>>>    }
>>>>>> doesn't work as well as being useless and irritating (it is 
>>>>>> supposed to just print 98 lines of COM names).
>>>>>> But since i isn't a string, post() crashes.
>>>>>> I'm looking into how to enumerate serial ports on Windows properly.
>>>>>> It looks like you have to open each device to find out about it, 
>>>>>> unlike on linux where they are listed as files.
>>>>>>
>>>>> So I changed it in cvs. Now you get a list of available serial 
>>>>> ports in Windows as well. At least it works for me but I only have 
>>>>> one port here so I don't know if it _really_ works.
>>>>>
>>>>
>>>> Now I'm trying it on linux where I have only two ports and I get 
>>>> the full list of 32 devices. Maybe we should try probing them all 
>>>> to see which ones actually exist?
>>>
>>> Nice work on the COM stuff, sorry for introducing a bug on Windows. 
>>> :-/  I'll be getting a WinXP autobuild machine up in the next couple 
>>> days, so that will help.
>>>
>>> That would be nice.  On Mac OS X, the exist if they are in the file 
>>> system.  On newer Linux-based systems, that is also the case.  But 
>>> the only manually created files are still prevalent.
>>>
>> They 'exist' virtually but there is not usually a real device to plug 
>> your cable into except for the first one or two entries. It seems 
>> like you have to open each virtual device and see if you get a valid 
>> handle. If you do then the hardware exists (and you have to close it 
>> again), otherwise you have to check the error code to see if it 
>> wasn't opened because it's already in use or because it isn't there.
>>
>> Martin
>
> I guess I meant that and vice versa: on Mac OS X, if they are in the 
> filesystem, they exist.  I think its the same with Linux udev systems.

udev looks nice but I guess not every linux has it.

> I am wary of opening and closing every port to test if its there 
> unless its absolutely necessary.  I don't know about Windows or 
> GNU/Linux, but some devices take a long time to open, so the whole 
> system hangs waiting for it.  The Apple modem is an example of that.

It seems like you have to get a file descriptor in order to get any 
information about a device, and the only way to get the descriptor is to 
open the device :(
Windows has higher-level functions for getting system information but 
they aren't in the core API.
On my Windows box COM3 seems to be a modem but the error returned is 
"invalid parameters" instead of "doesn't exist" or "permission denied" 
(when it's already open).
OTOH, in the infamous registry we have: 
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM which contains a list 
of all real serial devices. Maybe that's better?
Apples can be tricky, it can take almost a minute to get the cd tray to 
open...

>
>
> I suppose that the testing phase could be in a background thread, then 
> it wouldn't hang.  A simple thread that just iterated thru all 
> possible ports, testing to see what exists, then making a report to 
> the console and the status outlet when complete.
Also it might be better to do it only once at comport setup time.

Martin