Roman Haefeli wrote:
On Mon, 2007-11-12 at 18:36 +0000, Martin Peach wrote:
Roman Haefeli wrote:
hi all
when sending 'info' to comport, it outputs a bunch of messages to its right outlet to give you some information about the properties of the connection. however, if you use 'devicename <something>' to open a connection, 'info' tells you 'port 9999', which is of course wrong.
when
you do 'open 9999', not the same device gets opened, or more likely: no device gets openend at all.
9999 is just a placeholder to indicate that the device was opened by
name.
On Windows the correct index is given because all the ports are named
COM.
On linux and OSX they have more complex names and glob is used to
generate a
list of all ports and the index is just the order in the list. I can add that feature soon...
It's now implemented. You can open a port by name, like [devicename /dev/ttyS0(, and the [info( message will give the index.
Until then, in recent [comport]s you can send the [ports( message and
get a
list on the status outlet. For example: [ports( | [comport] | | [route ports] | [unpack 0 s] gives you pairs of index and name, which you could compare with the name
you
opened the port with to find the index.
i am working on a bunch of arduino abstractions that do find automagically the correct port of the arduino board. i decided to use different approaches on different os to probe the port of arduino. i experienced, that on linux the arduino sometimes appears on port 8, sometimes on port 48, probably it is different again on other linux flavors. in order to avoid 40 or more error messages before the correct port is found, i probe not with 'port [1-99]', but with 'devicename /dev/ttyUSB[0-20]' on linux, since the devicename seems to be consistent throughout all linux flavors. however, i would like to avoid, that several abstractions use all their own [comport] on the
same
port, since i encountered, that when several [comport]s are listening
on
the same port, not all [comport]s will always receive all messages. for all above reason i would need to know, what the actual port number is
of
a connection, even if the connection was opened using 'devicename /dev/ttyUSB[0-20]'.
It might be better to use only one [comport] and send the data to the abstractions with [send] and [receive] since normally opening a comport
will
fail to open a port if the same port is already in use.
yo, sorry, if my sentences have been too confusing, but this is exactly what i would like to achieve. i encountered, that it _is_ possible to run several [comport]s on the same port, but then sometimes data from the arduino board doesn't seem to reach all [comport] objects. that is why i would like to implement a kind of a singleton pattern, that automatically uses the already existing/connected [comport], if there is any and otherwise uses it's on [comport]. in order to achieve that, i need to know the port number, that a certain [comport] uses. this is very easy, if the connection was opened using a 'open' message, but if a certain [comport] established a connection using the 'devicename' method, then i don't know, which port this [comport] actually is using.
yo, what i am going to try now is to work with the 'port' method, as you proposed, so that i can find out, which device got which index (which actually should solve my problem)
can you tell me, how long the new [comport] has been in cvs? is it probably already part of the released pd-extended-0.39.3?
The [ports( message has been there since August 2007. Today I committed a new version to cvs. It sets the index properly when you open a port by name. It won't work if the port has a really odd name that isn't something like /dev/tty (because I can't guess what it's name might be and it can't be opened with an index number anyway) so in that case it's better to make a symlink with a "normal" name.
Martin