Hi, Those who are using Arduinos, Wiring and such interface could tell me if this little trick work for you too. This bash shell command on linux gives the material hardware port numbers that comport uses for USB serial communication in Pd.
i=0; for f in ls /dev/tty[US]*; do echo $i $f; i=$(( $i + 1 )); done
On my Debian laptop, it gives this:
0 /dev/ttyS0 1 /dev/ttyS1 2 /dev/ttyS10 3 /dev/ttyS11 4 /dev/ttyS12 5 /dev/ttyS13 6 /dev/ttyS14 7 /dev/ttyS15 8 /dev/ttyS16 9 /dev/ttyS17 10 /dev/ttyS18 11 /dev/ttyS19 12 /dev/ttyS2 13 /dev/ttyS20 14 /dev/ttyS21 15 /dev/ttyS22 16 /dev/ttyS23 17 /dev/ttyS24 18 /dev/ttyS25 19 /dev/ttyS26 20 /dev/ttyS27 21 /dev/ttyS28 22 /dev/ttyS29 23 /dev/ttyS3 24 /dev/ttyS30 25 /dev/ttyS31 26 /dev/ttyS32 27 /dev/ttyS33 28 /dev/ttyS34 29 /dev/ttyS35 30 /dev/ttyS36 31 /dev/ttyS37 32 /dev/ttyS38 33 /dev/ttyS39 34 /dev/ttyS4 35 /dev/ttyS40 36 /dev/ttyS41 37 /dev/ttyS42 38 /dev/ttyS43 39 /dev/ttyS44 40 /dev/ttyS45 41 /dev/ttyS46 42 /dev/ttyS47 43 /dev/ttyS5 44 /dev/ttyS6 45 /dev/ttyS7 46 /dev/ttyS8 47 /dev/ttyS9 48 /dev/ttyUSB1
My Arduino is at port number 48. So, I just need to initialize comport like this:
[comport 48 9600]
And then the communication is possible. I wrote this note int the dataflow wiki : http://wiki.dataflow.ws/comport
So, I only want to know if this bash command work on your setup too.
Cheers,
Alexandre Quessy http://alexandre.quessy.net/
On the latest version of [comport], the [info( message should print
out a similar output to the Pd window.
But yes, that script works for me.
.hc
On Sep 23, 2006, at 11:41 PM, Alexandre Quessy wrote:
Hi, Those who are using Arduinos, Wiring and such interface could tell me if this little trick work for you too. This bash shell command on linux gives the material hardware port numbers that comport uses for USB serial communication in Pd.
i=0; for f in
ls /dev/tty[US]*; do echo $i $f; i=$(( $i + 1 )); doneOn my Debian laptop, it gives this:
0 /dev/ttyS0 1 /dev/ttyS1 2 /dev/ttyS10 3 /dev/ttyS11 4 /dev/ttyS12 5 /dev/ttyS13 6 /dev/ttyS14 7 /dev/ttyS15 8 /dev/ttyS16 9 /dev/ttyS17 10 /dev/ttyS18 11 /dev/ttyS19 12 /dev/ttyS2 13 /dev/ttyS20 14 /dev/ttyS21 15 /dev/ttyS22 16 /dev/ttyS23 17 /dev/ttyS24 18 /dev/ttyS25 19 /dev/ttyS26 20 /dev/ttyS27 21 /dev/ttyS28 22 /dev/ttyS29 23 /dev/ttyS3 24 /dev/ttyS30 25 /dev/ttyS31 26 /dev/ttyS32 27 /dev/ttyS33 28 /dev/ttyS34 29 /dev/ttyS35 30 /dev/ttyS36 31 /dev/ttyS37 32 /dev/ttyS38 33 /dev/ttyS39 34 /dev/ttyS4 35 /dev/ttyS40 36 /dev/ttyS41 37 /dev/ttyS42 38 /dev/ttyS43 39 /dev/ttyS44 40 /dev/ttyS45 41 /dev/ttyS46 42 /dev/ttyS47 43 /dev/ttyS5 44 /dev/ttyS6 45 /dev/ttyS7 46 /dev/ttyS8 47 /dev/ttyS9 48 /dev/ttyUSB1
My Arduino is at port number 48. So, I just need to initialize comport like this:
[comport 48 9600]
And then the communication is possible. I wrote this note int the dataflow wiki : http://wiki.dataflow.ws/comport
So, I only want to know if this bash command work on your setup too.
Cheers,
Alexandre Quessy http://alexandre.quessy.net/
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If you are not part of the solution, you are part of the problem.
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.
Martin
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.
Martin
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?
Martin
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.
.hc
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
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
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.
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.
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.
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
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
Martin Peach wrote:
Hans-Christoph Steiner wrote:
filesystem, they exist. I think its the same with Linux udev systems.
udev looks nice but I guess not every linux has it.
this is correct, but it is _the_ standard way of doing it since..hmm...kernel-2.6.8 i think. and prior to this there was devfs, which provided the same functionality (kind of).
i would really suggest to _not_ probe each device whether it is actually valid, but instead to rely on a properly set up /dev-tree (either manually or via udev or similar).
blind probing is likely to hang your system.
getting the available devices (and making them accessible) is really a task of the operating system and not of any application.
mfg.asdr IOhannes
-
Alexandre Quessy -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach